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Abstract 


X.400  was  adopted  by  the  International  Telephone  and  Telegraph  Consul- 
tative Committee  (CCl  lT  )  in  1984  to  allow  different  electronic  mail 
systems  to  exchange  messages.  While  the  present  X.400  standard  does 
not  specifically  address  EDI,  its  architecture  is  sufficiently  open  so  that 
EDI  documents  can,  and  will,  be  incorporated.  A  movement  is  growing 
within  both  electronic  mail  and  EDI  circles  to  make  the  requisite  changes 
to  X.400  so  that  it  will  incorporate  EDI. 

The  purpose  of  this  report  is  to  explore  the  X.400  standard  so  that  service 
providers  and  end  users  will  understand  how  X.400  can  be  used  to  ex- 
change EDI  documents,  how  long  it  will  take  before  the  required  changes 
will  be  made,  and  what  the  likely  impact  will  be  on  the  EDI  and  elec- 
tronic messaging  industries. 

The  report  contains  78  pages  and  31  exhibits. 
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Introduction 


A  

Background  Electronic  Data  Interchange  (EDI)  provides  companies  with  highly 

significant,  operational  cost  savings  in  accounting,  shipping,  and  inven- 
tory management.  As  a  result,  value-added  service  and  timesharing 
providers  are  flocking  to  the  market  in  order  to  provide  valuable  EDI 
services  to  their  customers. 

Even  though  the  market  is  still  in  its  nascent  stages,  there  are  more  than 
30  companies  providing  EDI  services,  with  more  likely  to  enter  the 
market  during  the  next  several  years.  The  entry  of  multiple  service 
providers  poses  one  major  problem  for  users  and  providers:  How  do 
companies  who  use  one  service  provider  interchange  trade  documents 
with  companies  who  use  other  service  providers? 

There  are  three  ways  for  companies  to  exchange  EDI  documents: 

•  First,  the  companies  can  exchange  documents  directly  between  their 
computers. 

•  Second,  the  companies  can  subscribe  to  the  same  EDI  service  provider, 
which  gives  each  subscriber  a  mailbox. 

•  Third,  the  service  providers  themselves  can  interconnect  their  services, 
passing  EDI  documents  from  companies  subscribing  to  their  respective 
services. 

Each  of  these  solutions  illustrated  in  Exhibit  1-1  is  already  being  used  in 
the  market,  although  all  have  their  problems.  Direct  connection  between 
computers  seems  to  be  the  most  ideal  method  of  interconnection.  The 
myriad  protocols  in  use  on  different  computers,  however,  often  make 
direct  EDI  interconnection  impossible.  Even  if  the  protocol  problem 
were  solved,  however,  many  companies  cannot  afford  the  staff,  develop- 
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EXHIBIT  1-1 


ment,  and  communications  costs  required  to  be  ready  to  receive  EDI 
documents  from  multiple  trading  partners. 


THREE  WAYS  TO  INTERCHANGE 


Company 
A 


Direct  Connection 


Company 
B 


Same  .x 
Service  v> 


Services 
Connect 


Holding  mailbox  subscriptions  on  each  EDI  service  is  also  a  potentially 
effective  solution.  Unfortunately,  with  the  growing  number  of  service 
providers  in  the  market,  it  is  becoming  unwieldy  to  have  a  mailbox 
subscription  on  each  service. 

Service  provider  interconnection  also  sounds  like  an  excellent  solution. 
Instead  of  a  company  having  multiple  mailboxes,  each  company  needs 
only  one— with  the  service  providers  handling  the  delivery  among  their 
systems.  Unfortunately,  service  provider  interconnection  is  fraught  with 
problems,  including  keeping  a  single  directory  of  users,  keeping  an  audit 
trail  of  delivery  across  multiple  providers,  and  developing  a  settlements 
process  among  the  various  service  providers  so  that  EDI  tariffs  can 
evolve  with  regularity. 


The  X.400  Solution       The  problems  now  associated  with  EDI  interconnection  will  not  go  away 

soon.  There  is  hope,  however,  that  a  long-term  solution  can  be  devel- 
oped based  on  the  X.400  interconnection  standard.  The  X.400  solution 
was  adopted  by  the  International  Telephone  &  Telegraph  Consultative 
Committee  (CCITT)  in  1984  to  allow  different  electronic  mail  systems  to 
exchange  messages.  Although  the  present  X.400  standard  does  not 
specifically  address  EDI,  its  architecture  is  sufficiently  open  so  that  EDI 
documents  can  be  incorporated. 
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Although  X.400  will  not  solve  every  problem  associated  with  EDI  inter- 
connection, it  can  go  a  long  way  toward  providing  the  security  and 
regularity  that  EDI  users  require  from  any  interconnected  networks.  As  a 
result,  a  movement  is  growing  within  both  electronic  mail  and  EDI 
circles  to  make  the  requisite  changes  to  X.400  so  that  it  will  incorporate 
EDI. 

The  purpose  of  this  report  is  to  explore  the  X.400  standard  and  its  poten- 
tial impact  on  EDI  interconnection  so  that  service  providers  and  end  users 
will  understand: 

How  X.400  can  be  used  to  exchange  EDI  documents 
How  long  it  will  take  before  the  required  changes  will  be  made 
What  the  likely  impact  will  be  on  the  EDI  and  electronic  messaging 
industries 

Even  though  user  organizations  and  service  providers  have  made  the 
assumption  that  X.400  will  solve  a  number  of  problems  associated  with 
EDI  interconnection,  an  important  purpose  of  this  report  is  to  point  out 
that  the  X.400  standard  itself  is  only  one  piece  of  several  important 
elements  that  must  all  fall  into  place  before  today's  problems  can  be 
solved.  As  a  result,  service  providers  and  user  organizations  should  not 
raise  their  hopes  that  X.400  will  provide  a  short-term  solution  to  intercon- 
nection. 


The  study  addresses  the  following  topics: 

•  The  X.400  standard  and  how  it  can  be  used  technically  by  the  EDI 
industry 

•  How  long  it  will  take  to  change  X.400  so  that  it  can  be  used  for  EDI 

•  What  role  tariffs  and  interconnection  agreements  play  in  EDI  intercon- 
nection 

•  How  X.400  will  impact  today's  relationship  between  service  providers 
and  user  organizations 

•  How  service  providers  view  X.400's  impact  on  EDI 

•  How  user  organizations  view  X.400' s  impact  on  EDI 

•  The  likely  market  impact  of  X.400  on  the  EDI  industry 
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D  

Methodology  The  research  for  this  report  consisted  of: 

•  Corporate  Interviews 

-  Telephone  interviews  were  conducted  with  20  major  user  organiza- 
tions, trade  associations,  and  industry  experts  to  understand  their 
present  position  on  EDI  interconnection  and  their  view  of  X.400. 

•  Vendor  Interviews 

-  Telephone  interviews  were  conducted  with  15  vendor  organizations 
to  discuss  their  present  interconnection  activities  and  their  position 
on  X.400. 

•  X.400  Expert  Interviews 

-  Telephone  interviews  were  conducted  with  several  known  experts  in 
the  X.400  standards  community  to  understand  their  position  on 
X.400  and  EDI,  along  with  the  steps  that  are  being  taken  within 
major  standards  organizations  to  incorporate  EDI  into  X.400. 

•  Product  and  Service  Analysis 

-  INPUT  collected  information  on  X.400  itself  to  understand  from  a 
technical  viewpoint  how  EDI  can  be  incorporated  into  X.400. 
INPUT  also  analyzed  how  the  market  is  likely  to  react  to  X.400  when 
it  becomes  suitable  for  EDI. 

•  Custom  Research  Projects 

-  INPUT  has  been  involved  in  several  custom  research  projects  in  EDI 
and  Electronic  Mail.  Although  no  proprietary  information  is  used 
from  these  reports,  generic  information  and  general  industry  knowl- 
edge gained  from  these  studies  is  applicable  to  this  report. 

E  

Related  Studies  from     This  study  is  one  of  a  continuing  series  focused  on  EDI.  Other  reports 
INPUT  published  or  planned  for  the  series  include: 

•  EDI  Software  Products:  Issues,  Trends,  and  Markets 

•  EDI  Implementation  Case  Studies 

•  North  American  EDI  Service  Market  Analysis,  1988-1993 
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•  North  American  EDI  Service  Provider  Profiles 

•  Vertical  Industry  EDI  Directions  and  Potentials 

•  EDI  and  Professional  Services 

•  Network  Services  in  Western  Europe 

•  North  American  EDI  Software  Provider  Profiles 

•  International  EDI  Services 

•  Federal  Government  EDI  Initiatives 

•  Advanced  EDI  Services  (1989) 
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Executive  Overview 


A  

X.400  and  Open  Electronic  Data  Interchange  (EDI)  is  the  electronic  transfer  of  structured 

Systems  Integration       business  data  between  computer  applications  in  different  organizations. 

It  is  process-to-process  communication  in  machine-readable  formats  and 
overcomes  organizational  differences  in  computers,  protocols,  and  data 
formats. 

Over  the  past  decade,  the  EDI  industry  has  developed,  adopted,  and 
implemented  a  series  of  standards,  called  XI 2,  that  governs  how  EDI 
documents  are  exchanged.  At  present,  communication  of  EDI  documents 
takes  place  using  a  variety  of  low-level  communication  protocols,  includ- 
ing the  Universal  Communications  Standard  (UCS),  IBM's  binary  syn- 
chronous standard,  and  asynchronous  communication  protocols  like 
Kermit. 

Many  EDI  users  have  opted  to  use  public  EDI  services,  rather  than 
exchange  messages  directly,  for  three  reasons: 

•  There  is  no  single  protocol  accepted  by  all  users  in  the  industry. 

•  The  cost  of  operating  direct  communication  networks  under  any  of 
these  protocols  is  high. 

•  Many  companies  are  worried  about  connecting  their  sensitive  host 
processors  directly  to  communication  networks. 

When  using  a  public  service,  the  end  user  establishes  a  single  session 
with  the  service  provider  and  sends  EDI  interchanges  for  multiple  trading 
partners  and  then  retrieves  all  interchanges  sent  by  its  trading  partners. 
The  service  provider  acts  like  a  post  office  by  sorting  the  interchanges 
and  placing  them  into  the  mailboxes  for  specific  trading  partners.  In  this 
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way,  an  EDI  user  has  to  call  the  public  service  only  once  or  twice  daily 
to  perform  all  EDI  functions. 

To  provide  even  better  service,  the  EDI  service  providers  have  intercon- 
nected their  services  using  an  open-mailbox  concept.  Basically,  the 
service  providers  keep  mailboxes  on  each  others'  services,  so  that  an 
interchange  can  be  placed  in  the  mailbox  of  another  service  provider. 
The  interchange  is  retrieved  from  the  mailbox  and  then  delivered  to  the 
recipient  trading  partner's  mailbox.  In  this  way,  the  service  providers 
have  eliminated  the  need  for  EDI  users  to  keep  mailboxes  on  multiple 
services. 

In  1984,  the  X.400  Message  Handling  Standard  was  approved  by  the 
International  Telephone  &  Telegraph  Consultative  Committee  (CCITT) 
as  a  standard  that  would  allow  incompatible  electronic  mail  systems  to 
exchange  messages. 

X.400  is  a  high-level  communications  protocol  that  specifies  how  mes- 
sages are  exchanged  between  two  computers  and  is  part  of  the  growing 
trend  toward  Open  Systems  Integration.  Exhibit  II- 1  shows  the  OSI 
Reference  Model,  which  identifies  the  seven  levels  of  communications 
and  computing  systems.  X.400  functions  at  the  seventh  level  of  the 
model,  whereas  the  low-level  protocols  operated  by  most  EDI  users 
function  at  the  second  level. 


EXHIBIT  11-1 


OS!  SEVEN-LAYER  REFERENCE  MODEL 
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B  

X.400  Benefits  X.400  will  add  two  very  important  capabilities  to  electronic  messaging 

E-Mail  and  EDI  networks: 

•  X.400  will  provide  reliable  transport  of  messages  between  different 
message  systems,  complete  with  an  electronic  audit  trail. 

-  At  present,  today's  electronic  mail  gateways  are  all  proprietary, 
meaning  that  a  company  that  wishes  to  link  several  different  mail 
systems  must  have  several  different  gateways. 

-  To  make  matters  worse,  the  various  gateways  often  have  different 
levels  of  sophistication,  which  makes  it  almost  impossible  for  a  large 
company  to  develop  a  consistent  grade  of  service  among  its  different 
mail  systems. 

•  X.400  will  also  allow  a  worldwide  directory  of  electronic  mail  users  to 
evolve  via  its  companion  X.500  directory  standard. 

-  X.500  will  allow  many  different  mail  systems  to  keep  track  of  their 
users  in  a  standard  format  and  will  allow  users  on  one  system  to  find 
out  information  about  users  on  another  system. 

-  The  CCITT  has  already  set  up  the  idea  of  Administrative  Domains 
(public  services)  that  will  interlink  Private  Domains  (private  mail 
systems)  into  a  worldwide  network.  The  Administrative  Domains 
will  keep  track  of  the  many  different  Private  Domains  worldwide  and 
allow  them  to  allow  function  inside  a  worldwide  network. 

At  present,  X.400  has  been  implemented  by  most  leading  computer  and 
telecommunication  companies  worldwide,  although  end  users  are  just 
now  beginning  to  install  X.400  gateways  for  their  electronic  mail. 

Because  X.400  will  substantially  increase  the  intelligence  of  communica- 
tion among  different  electronic  mail  services  (while  also  providing  a 
consistent  level  of  service),  there  has  been  much  speculation  that  X.400' s 
benefits  can  be  extended  to  EDI.  In  September  1988,  the  CCITT  formed 
a  committee  to  create  a  modification  to  X.400  that  will  allow  it  to  handle 
EDI  documents.  The  committee  plans  to  have  a  working  version  ready 
by  the  end  of  1989. 

X.400  is  a  powerful  communications  protocol  that  will  be  used  by 
today's  public  service  providers  to  replace  Open  Mailbox  interconnec- 
tions. Even  though  the  Open  Mailbox  scheme  works  well,  X.400  will 
improve  reliability  through  audit  trails  and  will  also  facilitate  interna- 
tional EDI. 


EXEM 
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The  benefits  of  X.400  are  summarized  in  Exhibit  II-2. 


EXHIBIT  11-2 


X.400  BENEFITS  E-MAIL  AND  EDI 

•  Reliable  Intersystem  Transport 

•  Electronic  Audit  Trail 

•  Electronic  Directories 

X.400  Front-End 
Processors  for  EDI 


X.400  will  also  open  the  door  to  the  development  of  special  front-end 
processors  for  EDI  application  computers.  These  X.400  front-end  proc- 
essors will  perform  many  of  the  postal  functions  that  are  now  performed 
by  EDI  services,  particularly  routing  messages  between  trading  partners. 

The  X.400  front-end  processor  will  receive  a  stream  of  EDI  interchanges 
from  the  back-end  application  processor,  just  as  public  EDI  services  do 
today.  The  X.400  front-end  processor  will  then  sort  the  interchanges, 
wrap  them  in  X.400  envelopes  for  each  trading  partner,  and  send  the 
envelopes  to  the  Message  Handling  System  (MHS),  which  will  deliver 
the  envelopes  either  directly  to  the  trading  partners'  X.400  systems,  if 
possible,  or  to  the  trading  partners'  public  services. 


Exhibit  II-3  shows  how  an  X.400  front-end  processor  will  function. 
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EXHIBIT  11-3 


X.400  FRONT-END  PROCESSOR  FOR  EDI 
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X.400  Message  Transfer  System 


Readers  should  note  that  the  X.400  front-end  processor  that  INPUT 
envisions  will  not  be  a  "pure"  X.400  system.  Instead,  it  will  consist  of 
several  modules  that  perform  both  EDI  and  X.400  functions. 


•  One  module  will  break  EDI  batch  documents  into  separate  inter- 
changes. 

•  Another  will  map  EDI  interchange  addresses  to  communication  net- 
work addresses. 

•  Others  will  perform  communication  functions  associated  with  X.400. 

Thus,  the  X.400  front-end  processor  will  be  a  hybrid  system  that  is  a  true 
integration  of  two  separate  disciplines,  E-mail  and  EDI,  rather  than  a 
simple  wrapping  of  an  X.400  envelope  around  an  EDI  document. 


EXEM 
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X.400  Will  Impact  the  X.400  will  change  today's  EDI  industry  dramatically  by  shifting  the 
EDI  Service  Industry     technological  balance  away  from  using  public  service  providers  and 

toward  connecting  EDI  systems  directly. 

Technology  always  exists  in  a  balance  between  doing  it  yourself  or 
paying  someone  else  to  do  it.  In  the  1960s  and  1970s,  for  example,  the 
high  cost  and  complexity  of  computers  led  to  the  rise  of  the  timesharing 
industry. 

In  the  1980s,  the  high  cost  and  complexity  of  network  communications 
led  to  the  rise  of  public  EDI  services.  In  the  1990s,  X.400  will  allow  this 
balance  to  shift  back  toward  trading  partners  communicating  directly,  in 
much  the  same  way  that  the  personal  computer  caused  many  timesharing 
users  to  perform  their  applications  directly. 

X.400,  however,  will  evolve  slowly  in  the  market.  The  CCITT  will  not 
finish  its  work  until  the  end  of  1989  at  the  earliest.  It  will  be  1990  before 
the  first  prototype  systems  are  available.  These  prototypes,  furthermore, 
will  be  only  one  of  several  subsystems  that  must  be  integrated  to  form  a 
functional  X.400  front-end  processor.  For  this  reason,  INPUT  expects 
that  X.400's  impact  on  EDI  will  not  be  felt  until  1992. 

Exhibit  II-4  projects  the  market  impact  of  X.400  on  the  EDI  network 
service  industry. 

Out  of  an  industry  that  is  expected  to  grow  from  $178  million  in  1989  to 
$1.5  billion  in  1993,  X.400  is  expected  to  account  for  only  $144  million 
in  revenues  in  1993.  The  impact  of  X.400,  however,  will  be  much 
greater  than  meets  the  eye.  Direct  connections  will  transfer  revenues 
from  high-priced  EDI  services  to  low-priced  packet- switching  services 
and  regular  dial-up  telephone  calls.  Direct  X.400  connections  will  lower 
revenues  to  EDI  service  providers  by  a  factor  of  five. 

As  a  result  of  the  anticipated  impact  of  X.400  on  EDI,  INPUT  is  revising 
its  EDI  network  service  forecast  downwards  by  $120  million  in  1993 — 
from  $1.62  billion  to  $1.5  billion.  This  is  a  highly  significant  amount, 
especially  since  X.400  will  just  be  reaching  its  stride  in  the  market.  By 
the  1995-1998  period,  X.400  front-end  processors  will  likely  cause 
decline  in  the  overall  EDI  network  services  market,  even  though  traffic 
will  continue  to  grow  substantially. 


12 


O  1988  by  INPUT.  Reproduction  Prohibfted. 


EXEM 


EDI  AND  X.400 


INPUT 


EXHIBIT  11-4 
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X.400  Affects  the 
Market 


Today's  EDI  service  providers  will  not  all  be  hurt  by  X.400.  The  value- 
added  networks  (VANs) — such  as  Telenet,  Tymnet,  Western  Union, 
AT&T,  and  CompuServe — provide  lower-level  X.25  packet- switching 
services  as  well  as  higher-level  EDI  services.  Although  these  companies 
might  lose  potential  EDI  service  revenues,  they  will  gain  substantial 
packet- switching  revenues.  Thus,  they  will  benefit  under  any  scenario. 

Remote  computer  services  (RCSs),  on  the  other  hand,  are  particularly 
threatened  because  they  do  not  operate  their  own  lower- level  communi- 
cation networks.  These  firms — such  as  Control  Data,  Kleinschmidt,  and 
Sterling  Software — will  have  to  adjust  their  strategies  to  maintain  their 
position  in  the  industry.  Fortunately  (because  the  impact  is  several  years 
away),  they  have  the  time  and  specific  strategies  (described  in  this 
report)  that  will  allow  them  to  prosper. 

Although  network  services  will  be  hurt  by  X.400,  the  X.400  front-end 
processor  will  open  up  a  new  market  for  software  and  computer  equip- 
ment. In  the  1989-1993  period,  the  market  will  be  small,  growing  from 
an  estimated  $2  million  in  1990  to  $39  million  in  1993.  By  the  late 
1990s,  however,  this  market  will  explode  and  could  easily  reach  $200+ 
million  if  virtually  every  EDI  user  purchases  an  X.400  front-end  system. 

The  companies  who  dominate  this  market  niche  will  likely  do  so  via 
either  joint  ventures  or  acquisitions.  X.400  front-end  processors  will 
require  multidisciplinary  development  teams  that  understand  both  EDI 
and  X.400.  At  present,  there  are  few  companies  that  have  such  expertise 
and  even  fewer  that  have  it  under  the  same  roof.  As  a  result,  INPUT 
expects  that  small  EDI  software  firms,  X.400  software  companies,  and 
computer  equipment  companies  will  have  to  join  forces  either  by  joint 
ventures  or  acquisitions. 

The  market  effects  of  X.400  are  summarized  in  Exhibit  11-5. 


EXHIBIT  11-5 


X.400  AFFECTS  THE  MARKET 
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EXHIBIT  111-1 


Electronic  Data  Interchange  (EDI)  is  the  electronic  transfer  of  structured 
business  data  between  computer  applications  in  different  organizations. 
It  is  process-to-process  communication  in  machine-readable  formats  and 
overcomes  organizational  differences  in  computers,  protocols,  and  data 
formats  (see  Exhibit  IH- 1). 


ELECTRONIC  DATA  INTERCHANGE 


The  Application-to-Application  Exchange 
of  Intercompany  Business  Data 
in  Standard  Formats 


Although  typically  used  for  the  transfer  of  electronic  purchase  orders, 
invoices,  bills  of  lading,  and  other  trade  documents,  EDI  exchanges  are 
also  used  for  electronic  health  care  insurance  claims,  in  property/casualty 
insurance,  and  in  other  industries. 

EDI  is  being  developed  and  used  for  one  simple  reason:  it  saves  organi- 
zations enormous  amounts  of  time  and  money  because  information  can 
be  exchanged  in  machine-readable  format,  rather  than  transmitted  by 
physical  means  and  rekeyed  when  it  moves  from  one  organization  to 
another. 


EXEM 
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In  North  America,  EDI  standards  are  developed  by  several  different  trade 
industry  groups.  The  most  visible  EDI  standard  is  known  as  XI 2,  which 
is  developed  by  the  American  National  Standards  Institute.  The  X12 
standards  describe  the  coding  elements  for  business  documents,  a  proto- 
col for  how  these  elements  are  interpreted  once  they  are  passed  from  one 
computer  system  to  another,  and  several  different  methods  of  communi- 
cating EDI  documents. 

Different  industry  organizations — such  as  the  American  Paper  Institute, 
American  Trucking  Association,  Association  of  American  Railroads, 
Automotive  Industry  Action  Group,  Data  Interchange  Standards  Associa- 
tion, Transportation  Data  Coordinating  Committee,  Health  Industry 
Business  Communications  Council,  EDI  Council  of  Canada,  National 
Association  of  Refrigerated  Warehouses,  The  Uniform  Code  Council, 
etc. — are  all  active  in  defining  how  the  X 12  and  other  standards  are  to  be 
applied  in  their  respective  industries. 

In  some  cases — such  as  in  the  automotive,  chemical,  electrical  supplies, 
electronics,  and  office  products  industries — -XI 2  has  been  used  as  the 
basis  of  exchange  standards.  Other  industries,  such  as  grocery,  drug 
wholesaling,  aircraft  maintenance  and  automotive  parts,  keep  a  close  eye 
on  the  X12  standard,  but  still  adhere  to  electronic  standards  created 
before  X12  for  their  specific  industries. 

Internationally,  a  set  of  standards  called  ED  IF  ACT  (EDI  for  Administra- 
tion, Commerce,  and  Transportation)  is  evolving  for  use  within  Europe 
and  for  international  data  exchange. 


1.  The  X12C  Subcommittee 

The  ANSI  X12C  subcommittee  has  the  overall  responsibility  of  defining 
X12  communication  standards.  In  performing  its  work,  the  X12C  sub- 
committee has  built  heavily  upon  the  pre-existing  communication  tech- 
niques used  by  nonstandardized  EDI  industry  groups. 

•  In  practice,  for  example,  the  Universal  Communications  Standard 
(UCS),  which  was  developed  by  the  grocery  industry,  has  been  adopted 
by  most  EDI  groups  as  the  main  method  of  exchanging  EDI  docu- 
ments. 


B 


Communications  in 
EDI 


The  EDI  standards  process  within  ANSI  has  four  subcommittees  respon 
sible  for  creating  the  overall  X12  standard: 


•  X12A — Transaction  Set  Development 

•  X12B — Data  Mainenance  and  Liason 

•  X12C — Communication  and  Control  Structures 

•  XI  2D— Public  Relations 
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•  UCS,  in  essence,  is  IBM's  binary  synchronous  communications  proto- 
col to  exchange  batch  files  directly  between  computers. 

UCS  is  a  lower-level  protocol  whose  intelligence  is  limited  to  error-free 
communication  between  two  computers.  It  has  no  application-level 
intelligence  of  the  type  found  within  X.400.  The  EDI  industry  has 
adjusted  to  this  lack  of  an  intelligent  communications  protocol  by  build- 
ing intelligence  within  the  EDI  document  itself. 

•  To  give  one  example,  UCS  itself  has  no  audit  trail  to  track  whether  a 
specific  P.O.  or  invoice  was  delivered  between  two  user  organizations. 
X12  itself,  however,  has  special  documents  that  acknowledge  the 
receipt  of  a  P.O.  or  invoice. 

•  These  acknowledgement  messages,  which  are  called  functional  ac- 
knowledgements (FAs)  within  the  industry,  are  created  by  the 
recipient's  EDI  computer  after  receiving  the  documents  from  the 
sender. 

•  Although  FAs  increase  the  communications  overhead  for  EDI  trading 
partners,  they  provide  for  a  comprehensive  audit  trail  of  EDI  docu- 
ments. 

2.  Public  EDI  Service  Providers 

When  UCS  is  combined  with  FAs,  it  provides  an  effective  communica- 
tions environment  for  most  companies.  UCS  does  have  one  problem.  It 
requires  that  companies  support  the  cost  of  enough  communication 
channels  to  meet  the  expected  demand  of  daily  transmissions  between 
trading  partners.  In  order  to  make  such  direct  trading  easy,  all  of  the 
trading  partners  must  either  specify  times  at  which  the  exchanges  are  to 
take  place  or  have  enough  capacity  to  meet  peak  load  delivery  require- 
ments. 

EDI  service  providers  solve  the  problems  associated  with  operating 
private  communication  facilities  to  both  send  and  receive  EDI  data. 
These  EDI  service  providers — such  as  McDonnell  Douglas,  GE  Informa- 
tion Services,  Sterling  Software,  Kleinschmidt,  and  Control  Data — allow 
EDI  data  for  multiple  trading  partners  to  be  exchanged  with  a  single 
phone  call. 

•  The  end  user  calls  the  EDI  service  provider  using  one  of  several  poten- 
tial protocols,  sends  all  of  its  EDI  data  to  multiple  recipients,  and  then 
receives  all  of  the  EDI  data  that  has  been  sent  by  trading  partners. 

•  The  EDI  service  providers  perform  this  service  by  sorting  the  EDI  data 
into  "mailboxes"  for  each  subscriber.  The  service  providers  can  also 
perform  other  value-added  functions,  such  as  validation  checking  and 
file  format  translation. 
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Although  EDI  service  providers  give  users  an  easy  way  to  send  and 
receive  EDI  data,  the  force  of  competition  has  created  its  own  problem 
for  the  EDI  industry. 

•  EDI  is  considered  to  be  one  of  the  most  important,  if  not  the  most 
important  growth  market  in  value-added  services.  As  a  result,  value- 
added  service  providers  are  flocking  into  the  EDI  marketplace.  Each 
EDI  service  provider,  furthermore,  has  staked  a  claim  on  certain  EDI 
vertical  markets. 

•  As  a  result,  user  organizations  now  must  typically  subscribe  to  more 
than  one  mailbox  service  in  order  to  obtain  full  coverage  of  the  compa- 
nies with  whom  they  must  exchange  data.  As  EDI  spreads,  this  prob- 
lem will  only  get  worse,  not  better,  because  the  EDI  market  is  now 
poised  for  rapid  growth,  with  an  increasing  number  of  end-user  organi- 
zations and  service  organizations  entering  the  market. 

The  growing  number  of  service  providers  has  resulted  in  a  strong  de- 
mand from  EDI  users  to  have  their  data  sent  to  trading  partners  who  have 
mailbox  accounts  with  other  service  providers.  The  largest  example  is 
the  grocery  industry,  which  is  dominated  by  two  EDI  service  providers — 
Sterling's  OrderNet  and  McDonnell  Douglas'  EDPNet.  The  grocery 
industry  is  also  attracting  several  other  service  providers. 

INPUT'S  survey  research  finds  that  users  rate  the  importance  of  internet- 
working very  high,  as  shown  in  Exhibit  III-2. 


EXHIBIT  111-2 
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"On  a  scale  of  1  to  5,  how  important  is  it  that 
EDI  Networks  connect  to  each  other?" 
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As  a  result  of  the  demand,  EDI  service  providers  have  interconnected 
their  services  by  providing  each  other  with  reciprocal  or  "open"  mail- 
boxes. This  allows  a  customer  on  one  service  to  send  documents  to 
trading  partners  on  other  services. 

Even  though  the  interconnections  are  far  from  perfect,  lacking  such 
features  as  an  audit  trail  or  secure  transmission,  they  have  proven  to  be 
very  effective  in  practice  because  of  the  Functional  Acknowledgements 
(FAs)  that  are  routinely  sent  between  trading  partners.  While  the  two 
service  providers  may  not  keep  track  of  what  messages  are  exchanged, 
the  sender  expects  to  see  a  FA  associated  with  a  specific  trade  document 
within  a  specific  time  period  (typically  24  hours).  If  the  sender  does  not 
receive  a  FA,  the  sender  assumes  that  the  document  was  not  received 
properly  and  will  resend  it. 


The  X.400  Standard      Although  the  EDI  industry  seems  to  function  quite  well  with  its  existing 

method  of  communications,  not  all  users  are  happy  with  the  Open- 
Mailbox  concept  because  it  lacks  features  like  encryption,  audit  trails, 
and  security.  As  a  result,  experts  have  proposed  using  the  X.400  Mes- 
sage Handling  Standard  developed  by  the  International  Telephone  & 
Telegraph  Consultative  Committee  (CO  IT)  to  carry  EDI  data. 

From  a  business  viewpoint,  X.400' s  five  main  benefits  are: 

•  The  ability  to  serve  as  a  highly  reliable  gateway,  so  that  mail  systems 
from  different  vendors  can  exchange  information  in  a  standardized 
environment 

•  The  ability  to  allow  companies  to  communicate  with  customers  and 
suppliers  without  forcing  everyone  to  use  the  same  mail  system  or 
without  compromising  internal  security 

•  The  ability  to  allow  companies  to  develop  a  private  network  that  links 
computers  from  multiple  vendors 

•  The  ability  to  allow  companies  to  plan  and  implement  messaging 
systems  on  a  decentralized  basis  across  different  networks  without 
compromising  compatibility 

•  The  ability  to  evolve  into  a  single  network  architecture  for  a  wide 
variety  of  noninteractive  business  applications,  including  personal 
messaging,  document  distribution,  funds  transfer,  data  base  information 
transfer,  financial  planning  across  multiple  locations,  and  Electronic 
Data  Interchange  (EDI) 

These  points  are  conceptualized  in  Exhibit  HT-3. 


EXEM 
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X.400  BENEFITS— 
A  GATEWAY  BETWEEN 
DIFFERENT  SYSTEMS 


Mail  bystem  A 

w 

1 VI  all  Oyolcfll  D 

Computer  A 

—  Computer  B 

Network  A 

X.400 

—  Network  B 

Application  A  — 

< — 

—  Application  D 

B— 

E 

c— 

— > 

F 

1.  Value  of  X.400  to  EDI 

From  the  outset,  it  is  important  to  delineate  that  X.400 5 s  value  to  EDI  is 
very  much  in  the  eye  of  the  beholder. 

•  To  many  communications  companies  and  certain  EDI  users,  X.400 
will  solve  what  is  perceived  as  a  growing  problem  associated  with  EDI 
interconnectivity. 

•  Many  people  presently  using  EDI,  however,  do  not  perceive  that  they 
have  a  serious  problem  that  must  be  solved.  As  a  result,  there  is  no 
consensus  yet  about  X.400's  value  to  EDI. 

Thus,  while  X.400  is  a  promising  new  communications  technology,  two 
factors  must  be  kept  in  mind: 

•  First,  X.400  is  a  nascent  technology  in  its  first  stages  of  implementa- 
tion. Although  it  is  supported  by  virtually  every  communications  and 
computer  company  in  the  industry,  it  will  be  several  years  before  its 
implementation  becomes  widespread,  and  at  least  one  year  from  when 
this  report  is  published  before  the  CCITT  will  adopt  formal  recommen- 
dations to  integrate  EDI  and  X.400. 

•  Second,  EDI's  present  method  of  communications  works  quite  well  for 
most  users  and  certainly  cannot  be  considered  broken.  As  a  result, 
while  users  and  service  providers  may  say  kind  things  about  X.400, 
when  it  comes  time  to  pay,  especially  over  the  short-term,  they  may 
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well  prefer  to  leave  things  as  they  are  under  the  guise  that  "if  it  ain't 
broken,  don't  fix  it." 

•  In  short,  X.400  must  be  viewed  as  a  long-term  communications  tech- 
nology that  will  one  day  be  a  worldwide  standard,  rather  than  a  perfect 
solution  to  a  serious  and  pressing  problem. 

2.  Status  of  X.400 

Despite  the  attractiveness  of  X.400,  there  are  still  numerous  questions 
associated  with  its  ability  to  handle  EDI  data.  X.400  was  developed  as  a 
means  of  exchanging  interpersonal  information  between  human  senders 
and  receivers.  Its  developers,  however,  created  an  architecture  that  can 
be  used  to  send  machine-to-machine  information.  As  yet,  however,  the 
X.400  standard  does  not  specify  how  this  is  to  be  accomplished. 

X.400  also  does  not  specify  the  business  relationships  used  by  service 
providers  to  govern  interconnections.  These  business  relationships, 
called  settlements  in  the  telecommunications  industry,  specify  how 
different  service  providers  split  revenues  for  sending  messages  among 
and  between  other  service  providers. 

•  Without  a  standardized  settlements  system,  every  time  two  service 
providers  want  to  interconnect  their  services,  they  must  negotiate  a 
specific  relationship,  which  may  take  years  to  complete. 

•  With  a  specified  settlements  system,  however,  all  of  the  issues  and 
contracts  are  already  completed,  so  that  two  services  can  create  a 
relationship  quickly,  provided  they  are  willing  to  adhere  to  the  standard 
settlements  agreement. 

•  At  this  writing,  the  standards  group  within  the  CCITT  that  develops 
settlements  procedures  is  just  beginning  to  deal  with  X.400. 

At  present,  X.400  has  been  or  is  being  implemented  by  almost  every 
leading  computer  and  communications  organization. 

•  A  number  of  the  computer  industry  leaders  such  as  IBM,  Digital 
Equipment,  Data  General,  and  Hewlett-Packard — already  have  X.400 
systems  available  on  the  market. 

•  Several  leading  public  message  services — such  as  AT&T,  Telenet,  BT 
Dialcom,  Telecom  Canada,  and  MCI  Communications — have  imple- 
mented X.400  in  their  public  electronic  mail  services. 

•  Interestingly,  however,  none  of  the  public  services  in  the  U.S.  use 
X.400  to  interconnect  their  domestic  services.  Instead,  they  use  X.400 
to  communicate  to  private  electronic  mail  systems  or  to  other  services 
internationally. 
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Telenet  and  Dialcom,  for  example,  each  have  about  20  companies  that 
license  their  electronic  mail  software  worldwide.  Both  firms  plan  to  use 
X.400  to  allow  these  different  services  to  exchange  messages. 

•  Telenet's  Telemail  and  Telecom  Canada's  Envoy  100,  which  is  li- 
censed from  Telenet,  use  X.400  to  exchange  messages,  while  Dialcom 
in  the  U.S.  exchanges  messages  using  X.400  with  the  BT  Gold  service 
in  the  United  Kingdom.  Dialcom  is  owned  by  British  Telecom. 

•  Because  Telenet  and  Dialcom  are  competing  tooth-and-nail  to  be  the 
leading  electronic  mail  carriers  worldwide,  they  have  shown  little 
interest  in  interconnecting  their  services  to  date. 

EDI,  interestingly,  could  be  the  vehicle  that  compels  electronic  mail 
services  in  the  U.S.  to  interconnect  via  X.400.  While  few  of  these  serv- 
ices have  developed  interconnections  for  their  electronic  mail  services, 
most  of  the  EDI  services  now  are  interconnected  via  the  reciprocal 
mailbox  concept. 

•  Unlike  electronic  mail  users,  who  have  not  placed  a  lot  of  pressure  on 
electronic  mail  services  to  interconnect,  EDI  user  groups  have  de- 
manded that  their  service  providers  interconnect. 

•  As  electronic  mail  providers  enter  the  EDI  market,  they  will  be  faced 
with  the  reality  of  interconnecting  their  services  due  to  customer  de- 
mand. 

3.  Standards  Confusion 

X.400  at  the  moment  has  serious  problems  associated  with  its  basic 
development  cycle.  The  standard  itself  has  bogged  down  in  a  sea  of 
technical  complexity  and  changes,  which  will  delay  its  widespread 
implementation  in  the  marketplace. 

When  the  standard  was  adopted  in  1984  by  the  CCITT,  numerous  com- 
puter and  telecommunications  organizations  invested  more  than  $1 
million  each  to  develop  and  implement  working  versions.  These  organi- 
zations have  demonstrated  X.400  interconnection  at  several  major  trade 
shows  in  the  U.S.  and  Europe,  including  the  Hannover  Fair  and  the 
Enterprise  Networking  show.  These  companies,  however,  have  imple- 
mented the  1984  version  of  X.400. 

In  1988,  the  CCITT  adopted  a  new  version  of  X.400  that  included  sev- 
eral major  enhancements.  At  present,  these  firms  are  all  working  toward 
implementing  the  1988  version.  In  the  same  period,  the  International 
Standards  Organization  (ISO)  adopted  a  version  of  X.400  as  its  Message- 
Oriented  Text  Information  System  (MOTIS)  standard.  Unfortunately, 
while  MOTIS  and  X.400  are  similar,  they  are  not  identical,  which  has 
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added  an  additional  element  of  confusion  in  the  development  of  a  unified 
messaging  standard. 

A  third  area  of  confusion  for  X.400  is  the  development  of  the  X.500 
directory  standard.  X.500  provides  directory  services  for  X.400  and, 
potentially,  other  communication  systems.  Not  only  do  organizations 
have  to  worry  about  implementing  the  1988  version  of  X.400,  but  also 
they  have  to  worry  about  X.500  as  well.  Since  X.500  will  provide  a 
common  directory  of  users,  it  is  critical  for  any  all-encompassing  EDI 
interconnection  service. 

This  state  of  confusion  is  illustrated  in  Exhibit  III-4. 


STANDARDS  CONFUSION 


X.400  (1984) 

X.400  (1988) 

osi  <r 
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MOTIS 

X.500  | 
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To  make  a  long  story  short,  X.400  is  now  suffering  from  growing  pains. 

•  Because  it  encompasses  such  a  comprehensive  vision  and  has  many 
different  companies  contributing  to  its  development,  there  is  no  clear 
set  of  priorities  as  to  how  its  many  features  and  capabilities  should  be 
developed. 

•  Were  X.400  developed  by  a  single  company,  for  example,  its  many 
facets  would  be  implemented  in  staged  phases.  Since  it  is  being  devel- 
oped by  a  worldwide  community  of  companies,  however,  its  many 
facets  are  being  designed  in  parallel,  with  no  clear  plan  as  to  which 
capabilities  should  be  developed  in  which  order. 

•  To  give  one  example,  X.400  has  the  ability  to  provide  a  wide  range  of 
optional  protocol  translation  services.  Current  X.400  vendors,  how- 
ever, are  not  implementing  these  features. 

While  the  priorities  for  implementing  X.400's  capabilities  are  being 
adopted  in  a  haphazard  fashion  based  upon  which  capabilities  are  being 
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implemented  by  which  vendors,  this  is  likely  to  have  a  substantial,  posi- 
tive impact  on  the  speed  at  which  X.400  and  EDI  will  be  integrated. 

•  Companies  place  priority  on  implementing  features  that  they  believe 
will  have  a  direct  impact  in  the  market.  Since  virtually  every  company 
believes  that  there  will  be  a  strong  demand  to  use  X.400  to  exchange 
EDI  data,  vendors  will  almost  certainly  rush  to  meet  this  demand  at  the 
expense  of  implementing  other  features. 

•  Thus,  while  X.400  may  be  bogged  down  by  the  weight  of  its  own 
ambitious  capabilities,  there  is  a  strong  likelihood  that  allowing  X.400 
to  carry  EDI  information  will  receive  the  highest  priority  within  the 
X.400  community. 

4.  Technical  Overview  of  X.400 


X.400 's  development  is  closely  related  to  the  development  of  Open 
Systems  Interconnection  (OSI)  standards  within  the  International  Stan- 
dards Organization  (ISO).  X.400  and  OSI  have  their  roots  in  work  done 
within  the  International  Federation  of  Information  Processing  (IFIP)  in 
the  late  1970s.  The  computer  companies  took  this  work  into  the  ISO, 
while  their  communications  brethren  went  to  the  CCITT.  Exhibit  III-5 
shows  the  OSI  seven-layer  model. 
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a.  X.400  &  OSI's  Seven  Layers 

X.400  operates  at  the  application  (7th)  layer  of  the  OSI  model.  The 
application  specifies  how  messages  are  exchanged  between  sender  and 
recipient(s). 

•  The  messages  can  consist  of  text,  data,  graphics,  image,  or  voice  files. 

•  The  sender  and  recipient(s)  can  be  people  or  computer  programs  that 
perform  specific  tasks. 

Because  each  layer  of  the  OSI  model  operates  independently  of  the  other 
layers,  it  is  possible  to  operate  an  X.400  mail  system  over  any  type  of 
communication  roadway. 

b.  Basic  Structure  of  X.400 

X.400  has  two  major  subsystems:  the  Message  Transfer  Agent  (MTA) 
and  the  User  Agent  (UA). 

•  The  Message  Transfer  Agent  handles  the  delivery  of  messages  to  other 
Message  Transfer  Agents  or  to  User  Agents  within  its  own  sphere  of 
influence. 

•  The  User  Agent  represents  the  users,  accepts  messages  on  its  users' 
behalf,  keeps  track  of  the  mailboxes,  presents  messages  to  users,  and 
allows  messages  to  be  created. 

The  Message  Transfer  Agent  and  the  User  Agent  constructs  are  separated 
in  OSI's  7th  layer,  with  the  User  Agent  Layer  operating  above  the  Mes- 
sage Transfer  Agent  Layer.  In  this  way,  the  multiple  User  Agent  Layers 
can  be  developed  to  work  with  a  single  Message  Transfer  Agent  Layer, 
which  is  critical  for  the  development  of  a  User  Agent  designed  for  Elec- 
tronic Document  Interchange  (EDI). 

c.  Message  Structure  in  X.400 

An  X.400  message  has  three  parts:  Message  Transfer  Agent  service 
elements,  User  Agent  service  elements,  and  the  body  of  the  message. 

•  The  User  Agent  service  elements  and  the  body  part  constitue  the 
contents  of  the  message,  while  the  Message  Transfer  Agent  service 
elements  constitute  the  envelope. 

•  Service  elements  control  how  the  information  is  handled  by  both  the 
Message  Transfer  Agent  and  User  Agent. 
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•  The  Message  Transfer  Agent  service  elements  control  the  transfer  of 
messages  transparently  from  the  contents. 

•  The  User  Agent  service  elements  contain  the  actual  header  of  the 
message,  which  specifies  the  sender,  recipient(s),  subject,  and  other 
options  associated  with  creating  and  presenting  a  message.  The  User 
Agent  service  elements  created  for  interpersonal  messaging,  for  ex- 
ample, contain  the  To,  From,  Carbon  Copy,  and  Subject  fields  of  the 
message,  along  with  delivery  instructions,  such  as  the  message's  ur- 
gency, time  of  transmission,  and  importance. 

•  The  body  part  of  the  message  contains  the  information  being  commu- 
nicated. X.400  can  handle  ASCII  information  or  voice,  graphic,  video, 
or  other  formatted  data  streams.  It  even  has  the  ability  to  handle 
multiple  body  parts  within  the  same  message. 

Exhibit  ni-6  shows  X.400's  basic  architecture. 


OVERVIEW  OF  X.400's  ARCHITECTURE 
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d.  X.400's  Exchange  Protocols 


The  1984  version  of  X.400  has  three  protocols  associated  with  transmit- 
ting messages  between  different  Message  Handling  Systems:  PI,  P2,  P3. 
The  three  protocols  are  structured  methods  that  allow  the  body  parts  of 
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the  message  and  the  service  elements  associated  with  the  Message  Trans- 
fer Agent  and  User  Agent  to  be  exchanged  between  different  systems. 

•  PI  describes  how  two  Message  Transfer  Agents  exchange  information. 

•  P2  describes  how  two  User  Agents  exchange  interpersonal  messaging 
information. 

•  P3  describes  how  a  remote  User  Agent  exchanges  information  with  a 
Message  Transfer  Agent. 

In  the  1988  version  of  X.400,  a  fourth  protocol,  called  P7,  was  created. 
P7  describes  how  a  remote  User  Agent  exchanges  messages  with  a 
Message  Store  designed  to  temporarily  hold  messages. 

•  The  concept  of  the  Message  Store  and  P7  were  developed  when  it  was 
determined  that  P3  did  not  have  enough  features  to  support  remote 
personal  computers  signing  on  to  mail  systems  with  a  peer-to-peer 
protocol. 

•  As  a  result,  P3  will  fade  into  obscurity  and  P7  will  become  how  per- 
sonal computers  and  local-area  networks  dial  into  Message  Transfer 
Agents  to  exchange  messages  in  a  peer-to-peer  fashion. 

e.  Message  Transfer  Agent 

The  Message  Transfer  Agent  has  five  parts:  Basic,  Submission  and 
Delivery,  Conversion,  Query,  and  Status  and  Information.  Each  of  these 
parts  has  specific  service  elements  that  determine  the  features  available 
when  passing  messages.  Exhibit  III-7  shows  the  service  elements  in  the 
Message  Transfer  Agent. 

Two  of  the  Message  Transfer  Agent's  most  important  capabilities  are 
tracking  the  content  types  and  tracking  the  original  encoded  information 
types.  The  content  type  within  X.400  refers  to  the  specific  application  for 
the  message,  not  the  types  of  files  included  in  the  message.  At  present, 
the  CCITT  has  identified  two  content  types:  an  interpersonal  message 
(IPM)  and  an  interpersonal  message  status  report. 
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EXHIBIT  111-7 
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The  original  encoded  information  type  identifies  the  specific  format  of 
the  file  being  transmitted.  On  an  international  level,  the  original  encoded 
information  type  fields  identify  several  basic  types  of  message  formats, 
including: 


•  International  Alphabet  #5,  telex 

•  Teletex 

•  Groups  3  &  4  facsimile 

•  Voice 

•  Videotex 

•  Mixed  mode  (teletex  and  facsimile) 
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Another  message  format  is  what  the  CCITT  terms  a  simple  formattable 
document  (SFD),  which  is  a  series  of  paragraphs  that  can  be  formatted 
for  the  user  by  the  User  Agent.  In  addition,  X.400  also  defines  formats 
for  an  encrypted  document  and  a  forwarded  document. 

The  original  encoded  information  types  service  element,  in  theory,  can  be 
used  with  the  registered  encoded  information  types  and  converted  into 
service  elements  to  provide  automatic  format  translation  between  differ- 
ent types. 

•  This  translation  works  by  users  registering  the  types  they  can  receive. 

•  When  the  Message  Transfer  Agent  receives  a  message,  it  checks  the 
recipient's  registered  original  encoded  information  types  service  ele- 
ment and  performs  any  required  file  conversions.  None  of  the  vendors 
involved  have  yet  implemented  file  conversion  capabilities.  Thus, 
such  conversions  will  be  developed  as  X.400  evolves  in  the  market. 

f.  User  Agent 

Two  User  Agents  communicate  by  service  elements,  which  allow  com- 
mon mail  processing  functions  to  be  performed  across  X.400  systems. 
The  User  Agent  service  elements  are  described  in  Exhibit  III- 8. 


COOPERATING  USER  AGENT 
SERVICE  ELEMENTS 


Interpersonal  Messaging  (IPM)  Service  Elements 

Sender  and  i 
Recipients  9 

Message 
Relationships 

Contents  and 
Handling 

Delivery 
Status  | 

Originator              Message  ID 
Authorizing  Users     Reply  to 
Primary  Recipients  Forwarded 
Copy  Recipients  Obsoleting 
Blind  Copy  Cross- 
Recipients  Reference 

Subject 

Importance 

Sensitivity 

Autoforwarded 

Encryption 

Multipart  Body 

Expiry  Date 
Reply  by 
Receipt 
Nonreceipt 

The  best  way  to  understand  the  User  Agent  service  elements  is  through 
the  general  functions  that  must  be  performed  when  mail  systems  ex- 
change messages.  Each  general  function  has  a  series  of  service  elements 
associated  with  it  to  perform  the  tasks  required  for  message  delivery. 
These  functions  provide  information  about  the: 
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•  Sender  and  recipients 

•  Relationship  that  the  message  has  to  other  messages 

•  Contents  and  handling  of  the  message 

•  Delivery  status  of  the  message 

The  service  elements  that  provide  information  about  the  sender  and 
recipients  are  originator,  authorizing  users,  primary  recipients,  copy 
recipients,  and  blind  copy  recipients. 

The  service  elements  that  describe  the  various  relationships  the  message 
has  to  other  messages  on  the  system  are  the  message  ID,  reply  to  indica- 
tion, forwarded  indication,  obsoleting  indication,  and  cross-reference 
indication. 

The  service  elements  that  describe  information  about  the  contents  and 
handling  of  the  message  are  subject,  importance,  sensitivity,  autofor- 
warded,  body  part  encryption,  and  multipart  body. 

The  service  elements  that  describe  delivery  status  are  the  expiry  date 
indication,  reply  by  indication,  nonreceipt  notification,  and  receipt  notifi- 
cation. 

g«  Operation  of  X.400  Message-Handling  Network 

An  important  part  of  X.400  is  the  domain  structure  that  has  been  set  up 
by  the  CCITT  The  domain  structure  specifies  how  public  services  and 
private  systems  will  interact  to  form  a  worldwide  network. 

An  Administrative  Domain  (ADM)  is  a  public  mail  service  operated  by 
an  authorized  telecommunications  organization.  In  most  countries,  this 
will  be  the  Postal,  Telephone,  &  Telegraph  (PTT)  authority. 

A  Private  Domain  (PRDM)  is  operated  by  a  private  organization,  such  as 
a  large  commercial  company  or  government  organization. 

While  the  CCITT  envisions  that  Private  Domains  will  communicate  via 
Administrative  Domains,  the  ISO's  MOTIS  standard,  which  is  the  ISO's 
version  of  X.400,  allows  Private  Domains  to  communicate  directly, 
independent  of  the  CCITT' s  Administrative  Domain  structure. 

h.  X.400  and  Directories 

In  order  to  facilitate  a  global  mail  system,  the  CCITT  has  developed  the 
specifications  for  a  worldwide  directory  structure,  called  X.500,  which 
will  allow  specific  users  to  be  located  not  only  by  their  distinct  system 
name,  but  also  by  their  company,  department,  title,  and  other  personal 
attributes. 
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End  users  will  derive  two  major  benefits  from  the  X.500  directory  when 
it  is  implemented. 

•  The  first  benefit  is  the  ability  to  develop  a  cohesive  directory  of  all 
users  operating  on  the  company's  internal  network. 

•  The  second  benefit  of  X.500  will  be  to  allow  users  to  find  out  the 
correct  address  of  users  on  other  systems  worldwide  by  using  X.500' s 
directory  search  capability. 

i.  1984  versus  1988  Versions 

The  1988  version  of  X.400  adds  several  important  additions  to  the  1984 
version,  including  the  concept  of  a  Message  Store,  and  increased  security 
features — both  of  which  will  be  important  to  the  EDI  industry. 

•  The  Message  Store  will  allow  PC-based  EDI  systems  to  communicate 
directly  to  an  X.400  Message  Transfer  System  as  a  peer,  rather  than  as 
a  slave  system.  This  will  free  the  EDI  software  on  the  PC  from  having 
to  adhere  to  the  specifics  of  any  EDI  service. 

•  The  security  features  will  enable  EDI  documents  to  be  encrypted  within 
X.400's  architecture,  which  is  growing  in  importance  to  EDI  users  who 
are  worried  about  the  potential  for  sabotage  and  other  security-related 
problems. 

The  movement  to  the  1988  version,  however,  will  not  be  simple. 

•  Many  vendors  have  already  invested  heavily  in  X.400  without  any 
return,  only  to  discover  that  they  need  even  more  development. 

•  Furthermore,  many  of  these  vendors  purchased  X.400  source  code  from 
third  parties,  only  to  discover  that  they  had  to  make  extensive  enhance- 
ments themselves  to  fit  the  code  into  their  architectures. 

•  As  a  result,  although  these  companies  purchased  source  code  to  help 
them  with  their  initial  systems,  they  have  performed  enough  custom 
work  so  that  source  code  will  not  help  them  implement  the  new  X.400 
enhancements. 


X.400  and  EDI  While  the  above  description  of  X.400  may  be  tedious  for  a  nontechnical 

reader,  it  is  important  for  a  good  understanding  of  how  X.400  and  EDI 
can  interact  with  each  other. 


EXEM 


©  1988  by  INPUT.  Reproduction  Prohibited. 


31 


EDI  AND  X.400 


INPUT 


1.  Integrating  EDI  within  X.400 


The  key  to  integrating  X.400  &  EDI  is  the  separation  of  the  User  Agent 
and  Message  Transfer  Agent  Layers.  Multiple  User  Agents  can  use  the 
same  Message  Transport  Layer.  At  present,  the  only  User  Agent  that  has 
been  defined  is  for  Interpersonal  Messages.  The  protocol  is  called  P2. 

To  integrate  EDI  into  X.400,  a  new  User  Agent,  now  called  PEDI  within 
the  X.400  community,  must  be  developed.  The  structure  of  the  integra- 
tion of  EDI  and  X.400  is  shown  in  Exhibit  III-9. 


EDI  AND  X.400  INTEGRATION 


User 
ent 


Contents 


Contents 


P2  UA 
Layer 
Service 
Elements 


P-EDI 
UA  Layer 
Service 
Elements 


Trade 
Documents 


EDI  User 
Agent 


Message  Transfer 
Agent 


As  the  reader  can  see,  within  X.400's  architecture,  EDI  can  be  viewed  as 
another  User  Agent  with  its  own  set  of  service  elements. 

♦  These  service  elements  would  define  the  addressing  and  processing 
instructions  associated  with  an  EDI  document.  The  actual  trade  docu- 
ments would  then  be  placed  within  the  body  part  of  an  X.400  docu- 
ment. 
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•  In  this  way,  EDI  documents  would  be  placed  within  an  X.400  User 
Agent  and  exchanged  between  systems  by  the  Message  Transfer  Agent 
in  much  the  same  way  that  paper  documents  are  placed  in  envelopes, 
which  are  placed  in  mail  bags  and  physically  mailed  between  organiza- 
tions. 

While  this  may  seem  like  a  complicated  process,  the  basic  structure  of  an 
EDI  document  itself  provides  strong  guidelines  to  developers. 

•  A  basic  EDI  document  contains  all  of  the  information  required  to 
exchange  trade  documents. 

•  The  basic  strategy  for  using  X.400  to  send  EDI  documents  will  be  to 
read  the  exchange  information  within  an  EDI  document  and  use  it  to 
create  X.400  service  elements,  such  as  the  address  header. 

•  The  EDI  document  will  then  be  encapsulated  within  an  X.400  envelope 
and  transferred  using  the  powerful  features  with  an  X.400  MTA. 

2.  Industry  Perspectives  on  Integrating  EDI  and  X.400 

The  concept  of  integrating  EDI  and  X.400  has  existed  for  several  years. 
As  early  as  1984,  electronic  messaging  planners  were  looking  at  X.400  as 
a  vehicle  for  transferring  EDI  documents.  Such  a  view  was  primarily 
market  driven. 

•  Most  of  the  leading  electronic  mail  public  services  are  owned  and 
operated  by  telecommunication  companies  who  also  own  and  operate 
their  own  packet-switching  services. 

•  Electronic  mail  is  viewed  by  these  companies  as  an  application  that 
generates  traffic  for  the  underlying  packet- switching  network. 

•  EDI  is  viewed  by  these  companies  from  the  same  perspective.  Just  as 
these  firms  have  succeeded  in  generating  packet-switching  traffic  from 
their  electronic  mail  services,  they  also  believe  they  can  succeed  in 
generating  EDI  traffic. 

•  It  is  natural  that  leading  planners  in  these  companies  would  view  both 
personal  messaging  and  EDI  as  equivalent  User  Agents  for  their  Mes- 
sage Transfer  Agents. 

X.400  is  now  widely  viewed  within  the  electronic  messaging  world  as  the 
vehicle  for  carrying  EDI  data.  The  same,  however,  is  not  true  within  EDI 
circles.  The  difference,  more  than  anything  else,  is  in  perspective. 

•  Carrying  messages  is  the  primary  task  performed  by  the  electronic 
messaging  industry.  As  a  result,  the  contents  of  the  information  have 
always  been  of  secondary  importance. 
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•  The  EDI  industry,  in  contrast,  is  focussed  primarily  on  the  problem  of 
standardizing  the  trade  documents  exchanged  among  companies.  The 
transmission  of  these  documents  is  essentially  a  secondary  issue,  albeit 
an  important  one.  Thus,  the  EDI  and  X.400  worlds  see  the  same  prob- 

_               _                                                                              •                    1*1*1                     *        T"*-      1    "  1    *  .    TTT  1 

lem  from  a  reverse  perspective,  which  is  shown  in  Exhibit  111-10. 

EXHIBIT  111-10 

REVERSE  PERSPECTIVES  OF  EDI 
AND  X.400  INDUSTRIES 

\y  a  r\r\  U<Jn»tni 

X.400  Industry 

tui  industry 

[        X.400  B 

^40^ 

This  situation  can  be  shown  very  clearly  from  a  meeting  held  by  the 
Electronic  Mail  Association  in  Ft.  Lauderdale,  FL,  in  early  1988.  The 
meeting  was  attended  by  Paul  Lemme,  then  the  Executive  Director  of  the 
TDCC/EDI  Association,  and  Marshall  Spence,  President  of  the  EDI 
Council  of  Canada.  At  the  meeting,  electronic  mail  representatives 
waxed  eloquently  about  the  potential  of  marrying  EDI  and  X.400. 

Ted  Myer,  then  Director  of  Consulting  Services  for  Telenet  and  one  of 
the  leading  North  American  proponents  of  integrating  X.400  and  EDI, 
was  quoted  by  INPUT  as  saying  that  while  X.400  has  "awesome  poten- 
tial" for  transferring  electronic  mail,  it  has  "N-times-awesome  potential" 
for  sending  EDI  documents.  Note  that  his  quote  was  in  reference  to  the 
traffic  that  can  be  carried  over  messaging  networks. 

Myer  also  contended  that  today's  method  of  interconnecting  EDI  serv- 
ices— the  Open  Mailbox  concept — creates  a  logjam  in  the  industry. 
X.400,  he  argued,  would  break  the  logjam. 
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Marshall  Spence  said  that  directly  connecting  to  multiple  services  via 
UCS  was  basically  acceptable  to  Canadian  EDI  users,  who,  he  said,  did 
not  like  the  Open  Mailbox  concept  because  of  its  lack  of  security.  As  a 
result,  he  said,  X.400  was  a  clear  long-term  solution  and  suggested  that  it 
might  be  valuable  within  a  year  for  U.S. /Canadian  EDI  links. 

Paul  Lemme,  however,  painted  a  very  different  picture.  Lemme  aban- 
doned his  prepared  comments  because  he  was  upset  by  what  he  believed 
was  a  somewhat  insular  view  of  EDI  within  the  electronic  mail  industry. 

•  After  hearing  what  he  considered  to  be  enough  about  X.400,  Lemme 
said  there  were  other  working  alternatives  in  the  market,  the  most 
simple  of  which  was  to  connect  directly  with  trading  partners  using  the 
UCS  standard. 

•  Lemme  contended  that  UCS  is  ignored  by  the  electronic  mail  industry, 
which  still  believes  there  is  a  serious  communications  problem  in  the 
EDI  world.  Lemme  said,  "I  think  we're  looking  at  a  problem  which  has 
been  solved,  and  by  failing  to  recognize  that  solution,  we  spend  a  lot  of 
time  in  meetings  and  not  moving  forward  very  quickly." 

While  the  views  of  these  three  people  are  hardly  definitive,  they  illustrate 
an  underlying  tension  between  the  goals  of  the  EDI  and  communications 
industries. 

•  The  EDI  industry  doesn't  have  any  stake  in  how  trade  documents  are 
interchanged  as  long  as  the  solution  allows  them  to  do  business  prop- 
erly. 

•  The  communications  industry,  on  the  other  hand,  has  already  invested 
over  $100  million  collectively  in  developing  and  implementing  X.400 
and  intends  to  see  that  it  is  utilized  for  as  many  applications  as  possible. 

3.  EDI  and  X.400  Standards  Bodies 

There  is  another  subtle,  but  important,  issue  associated  with  the  marriage 
of  EDI  and  X.400:  how  will  such  a  standard  be  created? 

The  EDI  industry  is  structured  vertically,  consisting  of  multiple  standards 
bodies,  each  of  which  typically  operates  in  relationship  to  its  own  indus- 
try. The  only  non-vertical  organization  directly  involved  with  EDI  in  the 
U.S.  is  the  American  National  Standards  Institute. 

In  contrast,  X.400  is  controlled  by  two  international  bodies — the  CCITT 
and  ISO,  which  controls  the  MOTIS  standard,  which  is  X.400  by  another 
name. 
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MOTIS  and  X.400,  despite  the  different  names,  are  largely  identical. 
The  major  difference  is  that  since  CCITT  deals  with  standards  for  offi- 
cial telecommunications  organizations,  while  the  ISO  deals  with  stan- 
dards for  private  organizations,  X.400  is  structured  to  connect  private 
organizations  via  public  services,  while  MOTIS  is  structured  to  allow 
private  companies  to  communicate  directly. 

North  American  organizations  represent  themselves  directly  in  both  the 
CCITT  and  ISO.  When  voting  to  adopt  standards,  however,  only  recog- 
nized telecommunications  firms  are  allowed  to  vote  in  the  CCITT,  while 
only  the  U.S.  Department  of  State  is  officially  recognized  within  the  ISO. 
The  U.S.  Department  of  State  looks  to  the  National  Bureau  of  Standards 
(NBS)  for  guidance  on  telecommunications  issues.  The  NBS,  in  turn, 
looks  to  specific  business  and  government  organizations  to  define  its 
positions. 

For  EDI  to  be  incorporated  within  X.400,  it  first  must  be  adopted  by  both 
the  CCITT  and  ISO,  which  places  it  well  beyond  the  span  of  control  of 
the  EDI  industry.  This  is  a  potentially  dangerous  situation  for  companies 
planning  the  X.400-EDI  standard. 

•  Unless  the  standard  meets  the  needs  of  EDI  users  and  is  accepted  by 
the  EDI  standards  community,  any  incorporation  of  EDI  into  X.400 
runs  the  risk  of  being  ignored.  To  put  it  simply,  EDI  users  now  have 
solutions  to  their  problems  of  interconnection,  regardless  of  how 
imperfect  they  may  be.  Even  if  X.400 5  s  planners  develop  a  better 
solution,  EDI  users  can  very  easily  ignore  it  and  plod  ahead  using 
existing  techniques  of  communication. 

•  In  contrast,  once  X.400  is  agreed  upon  by  the  CCITT,  tremendous 
pressure  is  placed  on  both  computer  and  telecommunication  firms  to 
conform,  particularly  by  the  European  community. 

As  a  result  of  this  market  reality,  while  the  X.400  standards  community 
is  taking  the  lead  in  designing  the  connection  between  EDI  and  X.400, 
they  are  soliciting  the  active  participation  of  EDI  standards  experts. 

•  In  North  America,  the  two  leading  bodies  studying  EDI  and  X.400  are 
the  National  Bureau  of  Standards  (NBS)  and  ANSI,  both  of  which 
operate  Special  Interest  Groups  on  X.400  and  EDI  activities. 

•  The  ANSI  committee  on  X.400  has  met  regularly  during  the  last  two 
years  and  recently  recommended  that  EDI  documents  should  be  incor- 
porated within  the  existing  X.400  standard  by  using  a  subset  of  the  P2 
protocol. 
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4.  CCITT  Officially  Involved 

While  ANSI,  NBS,  and  any  other  organization  is  free  to  take  any  position 
it  wishes  on  X.400  &  EDI,  the  game  really  must  be  played  within  the 
CCITT  itself. 

At  the  final  plenary  for  the  CCITT's  1984-1988  Study  Group  period  (the 
CCITT  works  in  four-year  cycles),  Study  Group  VII,  which  develops  the 
X.400  standard,  approved  a  Study  Question  on  EDI.  On  August  1-3, 
1988  in  Ipswich,  U.K.,  the  first  formal  meeting  was  held  on  the  issue  of 
incorporating  EDI  into  X.400.  Ted  Myer,  formerly  of  Telenet,  is  the 
interim  Rapporteur  (leader)  of  the  Group  on  EDI. 

At  the  first  meeting,  the  Group  set  a  goal  that  its  work  would  be  com- 
pleted within  a  two  year  period  and  would  be  published  under  the 
CCITT's  Accelerated  Procedures,  which  allows  a  Group  to  release 
working  standards  documents  before  the  completion  of  the  CCITT's 
traditional  four-year  study  cycle.  This  means  that  the  CCITT  will  likely 
formally  adopt  a  position  on  EDI  and  X.400  in  the  late- 1989  or  early 
1990  time  frame. 

Exhibit  ni-1 1  lists  the  North  American  organizations  who  attended  the 
first  X.400-EDI  meeting. 

In  all,  20  firms  were  represented,  several  of  them  by  European  represen- 
tatives. Conspicuously  missing  were  official  representatives  from  any  of 
the  EDI  standards  bodies  in  the  U.S.,  although  there  were  several  people 
who  are  primarily  involved  in  EDI  standards  and  who  have  spent  several 
years  working  on  the  issue  of  X.400  &  EDI. 

At  the  meeting,  several  key  decisions  were  made.  The  four  most  impor- 
tant decisions  were  to: 

•  Create  a  separate  P-level  protocol,  called  PEDI  for  EDI,  rather  than  make 
any  attempt  to  implement  EDI  using  the  existing  P2  protocol  for  inter- 
personal messaging 

•  Develop  the  new  protocol  by  using  as  many  of  the  constructs  from  P2 
as  possible,  including  the  idea  of  a  separate  header  and  body 

•  Use  the  Message  Store  and  security  features  as  defined  in  the  1988 
version  of  X.400 — The  Message  Store,  however,  will  have  to  be  en- 
hanced to  include  logging  and  audit  features,  which  itself  will  require  a 
change  to  the  1988  version  of  X.400. 

•  Restrict  the  scope  of  activity  to  store-and-forward  exchange  of  EDI 
documents  that  adhere  to  the  EDIFACT,  ANSI  XI 2,  and  UN/TDI 
standards 
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EXHIBIT  111-11 


NORTH  AMERICAN  FIRMS  AT 
FIRST  EDI  AND  X.400  MEETING 
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McDonnell  Douglas 


MCI  International 


Microtel  Pacific  Research 


Pacific  Bell 


Prime  Computer 
Sydney  Development 


Telenet 


Texas  Instruments 


Wang  Labs 


Western  Union 


These  decisions  will  have  several  specific  impacts.  They  are: 

•  No  attempt  will  be  made  to  supplant  the  UCS  standard,  which  basi- 
cally describes  interactive  transfer  of  EDI  documents  between  two 
parties.,  Using  X.400  for  EDI  transfers  is  viewed  within  the  CCITT  as 
a  store- and-forward  system,  not  a  system  for  direct  interconnection. 

•  PC  software  will  be  able  to  interact  with  X.400  Message  Handling 
Systems  in  a  peer-to-peer  fashion,  which  will  allow  PC  software 
developers  to  create  one  version  that,  in  theory,  should  work  with  any 
public  service  that  adheres  to  the  X.400-EDI  standard.  It  should  be 
noted,  however,  that  if  audit  trails  and  logging  are  required,  the  X.400 
Message  Store  requirements  will  themselves  have  to  be  changed. 

•  The  work  done  by  the  ANSI  X12C  committee  on  implementing  EDI 
by  using  the  P2  layer  will  most  likely  be  ignored.  While  this  will  delay 
the  use  of  X.400  to  pass  EDI  data,  it  puts  to  rest  one  of  the  key  issues 
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of  the  past  few  years  —  whether  or  not  a  new  User  Agent  is  required. 
The  CCITT  has  formally  decided  to  develop  a  new  protocol,  the  specif- 
ics of  which  will  be  developed  in  the  next  few  months. 

5.  X.400  and  Efficiency 

While  there  is  no  doubt  that  X.400  can  be  adapted  to  carry  EDI  docu- 
ments, there  is  a  serious  question  whether  end  users  will  benefit  by  using 
X.400  directly.  When  an  EDI  document  is  created,  it  has  Interchange 
Control  Information  that  describes  the  EDI  document.  This  is  shown  in 
Exhibit  m-12. 


EDI  INTERCHANGE  STRUCTURE 


Interchange  Header  — — 
Functional  Group  Header  — 

Transaction  Set  Header  - — 
Application  Data 

Transaction  Set  Trailer  

Functional  Group  Trailer  — 

Interchange  Trailer  — 


An  EDI  document,  in  its  simplest  form,  consists  of: 

•  An  Interchange  Header,  which  describes  information  about  the  trading 
partners 

•  A  Functional  Group  Header,  which  describes  information  about  the 
specific  EDI  trade  documents  being  carried  within  the  overall  document 

•  A  Transaction  Set,  which  describes  the  specific  EDI  document 

•  The  Application  data,  which  is  the  information  being  exchanged 

The  Interchange,  Functional  Group,  and  Transaction  Set  are  building 
blocks  that  can  be  used  to  create  complex  EDI  documents.  As  an  ex- 
ample, it  is  possible  for  a  single  EDI  communication  to  have  multiple 
Interchange  Headers  and  Trailers,  multiple  Functional  Groups  nested 
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within  each  Interchange  Header/Trailer  and  multiple  Transaction  Sets 
within  each  Functional  Group. 

Since  an  EDI  document  is  also  self-contained,  lower-level  protocols  like 
the  bisynchronous  UCS  or  asynchronous  Kermit  are  very  efficient  trans- 
fer mechanisms.  These  protocols  merely  pass  the  EDI  documents  be- 
tween two  systems  that  have  been  set  up  to  decode  the  Interchange 
Control  Information. 

No  matter  how  much  the  telecommunications  industry  may  try  to  say 
otherwise,  X.400  is  going  to  add  considerable  overhead  versus  UCS  or 
Kermit  when  transmitting  the  same  EDI  documents. 

•  The  X.400  software  will  read  the  Interchange  Control  Information  in 
the  original  EDI  document  and  reformat  the  information  to  create  an 
appropriate  X.400  address. 

•  The  EDI  document  and  its  control  information  will  end  up  encapsu- 
lated within  an  X.400  message. 

One  has  to  ask  why  end  users  will  willingly  incur  extra  overhead  when 
UCS  or  Kermit  will  result  in  the  exact  same  information  transfer?  This 
redundancy  is  shown  in  Exhibit  III- 13. 


EXHIBIT  111-13 


X.400  REDUNDANCY  AND  OVERHEAD 
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This  issue  has  short-  and  long-term  implications. 

•  Over  the  long-term,  the  world  will  migrate  to  international  communica- 
tion standards,  especially  when  the  standards  become  entrenched  in 
operation. 

•  In  the  short-term,  however,  the  majority  of  EDI  users  will  not  require 
X.400  to  transfer  trade  data,  although  there  may  be  some  benefits. 

EDI  service  providers  have  a  different  viewpoint.  The  Open  mailbox 
concept,  while  effective,  lacks  an  intercompany  directory,  audit  trails, 
encryption  and  other  security  measures.  The  service  providers,  many  of 
whom  are  implementing  X.400  for  their  electronic  mail  users,  can  use 
X.400  to  exchange  EDI  data  as  well,  which  will  allow  them  to  provide 
better  services  for  their  end  users. 

6.  X.400,  Mailbox  Float,  and  JIT 

X.400  may  have  one  significant  advantage  over  today's  EDI  systems. 
X.400  is  designed  as  a  forced  delivery  system  in  which  the  sending  MTA 
contacts  the  receiving  MTA  to  deliver  a  document. 

•  If  an  end-user  organization  sets  up  an  X.400-based  front  end  processor 
to  its  EDI  application  system,  then  the  user  will  be  able  to  receive  EDI 
documents  directly  from  another  end  user  or  from  a  public  service 
provider  without  calling  up  to  check  a  mailbox.  This  will  eliminate  any 
"mailbox  float"  that  presently  exists. 

•  Assuming  that  an  organization  checks  its  mailboxes  once  or  twice  a 
day,  it  can  speed  up  the  reception  and  delivery  of  EDI  data  by  several 
hours. 

•  The  cost  will  be  in  the  vicinity  of  $1,000  per  month  plus  forced  deliv- 
ery charges  and  the  cost  of  an  X.400  gateway,  which  should  be  in  the 
vicinity  of  $10,000  to  $20,000.  This  is  a  relatively  small  amount  for 
large  or  medium-sized  firms  and  can  have  a  significant  benefit  for  just- 
in-time  inventory  applications. 

7.  Rates  and  Settlements 

While  the  technical  aspects  of  the  X.400  standard  are  obviously  impor- 
tant to  the  success  of  using  X.400  to  carry  EDI  documents,  they  are  only 
one-half  of  the  overall  equation.  Of  equal  importance  are  issues  related 
to  rates  and  settlements. 

The  settlements  process  itself  began  a  century  ago  when  telegraph  sys- 
tems were  interconnected  throughout  Europe.  The  process  was  extended 
to  the  telephone  and  telex  networks  and  is  the  unsung  hero  in  enabling 
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countries  to  interconnect  their  communication  systems  because  it  man- 
dates policies  for  making  such  interconnections. 

No  set  of  settlements  exists  to  govern  domestic,  North  American  or 
international  X.400  interconnections,  which  is  critical  to  the  long-term 
evolution  of  X.400-based  EDI  services. 

At  present,  EDI  service  providers  must  agree  upon  their  own  procedures 
when  interconnecting  their  services.  Interestingly,  while  the  service 
providers  are  virtually  all  connected  technically,  they  have  done  so 
without  reaching  any  formal  business  relationships.  Instead,  the  inter- 
connections are  based  upon  what  can  be  called  the  Agent  Theory. 

•  Basically,  the  EDI  service  providers  interconnect  to  each  other  as 
"agents"  for  their  customers.  During  the  interconnection,  messages  are 
exchanged. 

•  The  service  providers,  however,  have  no  audit  trail  procedures  to  track 
messages  across  the  interconnections  and  do  not  split  revenues.  While 
the  lack  of  an  audit  trail  may  surprise  non-EDI  readers,  it  should  be 
kept  in  mind  that  all  EDI  trading  partners  use  Functional  Ac- 
knowledgements (FAs)  as  a  means  of  confirming  that  documents  were 
received.  Thus,  when  trading  partners  use  Open  Mailboxes,  the  FAs 
act  as  positive  acknowledgements  that  messages  were  received. 

•  If  the  sender  does  not  receive  a  FA  within  a  specified  time  period,  the 
original  document  is  resent.  Thus,  while  the  Open  mailbox  intercon- 
nection does  not  have  an  audit  trail  capability,  the  end  users  already 
have  a  positive  acknowledgement  system  in  place,  which  provides  the 
same  capability. 

Despite  the  lack  of  formal  business  relationships,  most  EDI  service 
providers  are  creating  a  de  facto  standard  on  interconnection  that  works 
in  this  fashion: 

•  Users  who  wish  to  interconnect  pay  a  flat  monthly  fee,  usually  $15  to 
$25 

•  The  sender  then  pays  the  service  provider's  regular  rate  for  sending 
EDI  documents,  which  is  typically  based  upon  time  and  characters. 

•  The  service  provider  pays  the  costs  of  transmitting  messages  to  other 
service  providers 

The  idea,  of  course,  is  that  transmissions  and  receptions  will  cancel  each 
other  out.  Every  EDI  message  generates  a  minimum  of  a  return  ac- 
knowledgement and  can  often  generate  a  corresponding  EDI  document. 
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•  A  purchase  order,  for  example,  will  generate  an  acknowledgement  of 
receipt  from  the  recipient,  and  may  also  generate  a  corresponding 
invoice  and  resulting  acknowledgement.  It  can  also  generate  a  shipping 
document  to  the  shipper,  along  with  documents  to  warehouses,  etc. 

•  Thus,  service  providers  believe  it  is  in  their  long-term  interests  to 
generate  transactions  by  allowing  interconnections.  They  have  done  so, 
interestingly,  by  avoiding  any  formal  settlements  system  with  other 
service  providers. 

8.  X.400  and  Interconnection 

While  X.400  will  almost  certainly  play  an  important  role  in  EDI  intercon- 
nection on  an  international  level,  it  is  not  clear  how  important  its  role  will 
be  for  domestic  communications.  EDI  service  providers  already  are 
interconnected  and,  when  TAs  are  used,  basically  get  the  job  done. 
X.400,  however,  can  open  up  a  new  vista  for  EDI  service  providers  and 
user  alike  because  of  its  ability  to  allow  a  forced  delivery  network  to 
replace  today's  mailbox-oriented  network. 

This  has  interesting  implications  for  end  users  and  service  providers 
alike.  Large  end  users,  for  example,  will  be  able  to  install  X.400  front- 
end  systems  to  send  and  receive  EDI  documents  from  either  private 
trading  partners  or  public  services.  As  X.400  becomes  more  common,  it 
raises  the  interesting  question  of  whether  today's  public  EDI  services  will 
be  pushed  out  of  the  market  as  trading  partners  exchange  documents 
directly.  This  critical  issue  is  explored  later  in  this  report. 

The  next  chapter  examines  X.400  trends  and  their  likely  impact  on  EDI. 
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Trends  in  EDI  and  X.400 


The  emergence  of  EDI  and  X.400  are  occurring  simultaneously — with 
both  technologies  coming  together  from  different  directions.  This  section 
explores  the  trends  in  the  merger  of  EDI  and  X.400. 


Key  Differences  While  X.400  has  a  lot  of  promise  for  EDI,  it  is  important  to  understand 

Between  X.400  and       some  key  differences.  There  are  two  major  architectural  differences 
gpjj  between  EDI  and  electronic  mail:  addressing  and  auditing. 

1.  The  Addressing  Factor 

Addressing  is  a  functional,  not  technical,  issue. 


One  of  X.400's  strongest  boons  to  electronic  mail  is  the  X.500  Directory 
standard,  which  will  allow  a  directory  of  electronic  mail  users  to  evolve 
worldwide.  The  X.500  directory  will  allow  a  sender  to  find  a  recipient's 
address  across  many  different  electronic  mail  systems  and  will  also  allow 
high  level  addresses  to  be  mapped  to  specific  machine  addresses. 

This  has  an  underlying  assumption:  electronic  mail  users  need  a  world- 
wide directory.  Most  experts  in  the  field  believe  this  to  be  true. 

•  While  most  telecommunications  industry  proponents  have  assumed  that 
the  same  situation  is  true  in  EDI,  there  is  a  structural  difference  be- 
tween electronic  mail  and  EDI  that  brings  this  into  question. 

While  both  electronic  mail  and  EDI  public  services  give  mailboxes  to 
their  users,  the  two  have  very  different  addressing  structures. 

•  In  electronic  mail,  each  user  within  a  contiguous  addressing  group  has 
unrestricted  sending  ability  to  every  other  user. 
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•  On  most  EDI  services,  in  contrast,  only  defined  trading  partners  can 
exchange  messages.  Instead  of  open  pools  of  mailboxes,  like  in  elec- 
tronic mail,  EDI  services  are  really  a  series  of  restricted  trading  pairs. 

Exhibit  IV- 1  shows  these  differences. 


EXHIBIT  IV-1 


COMPARISON  OF  E-MAIL 
AND  EDI  ADDRESSING 


Electronic  Mail  Service 
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EDI  Service 


The  underlying  business  needs  show  how  these  differences  developed. 


In  electronic  mail,  the  basic  goal  is  to  allow  everyone  within  a  defined 
group  to  communicate  on  an  "as  required"  basis. 

•  In  private  mail  systems,  for  example,  the  lowliest  employee  can  send  a 
message  directly  to  the  highest  employee. 

•  In  theory,  this  can  be  extended  on  a  worldwide  basis  with  the  X.500 
directory  in  much  the  same  way  that  directory  services  exist  worldwide 
for  telephone  numbers.  In  fact,  X.500  has  the  potential  to  replace 
existing  directory  services. 

In  EDI,  trade  documents  are  exchanged  as  the  result  of  a  formal  business 
relationship,  which  is  usually  formulated  by  contract  specifying  that 
trade  documents  will  be  exchanged  electronically. 

•  In-house  EDI  systems  are  not  set  up  to  receive  trade  documents  elec- 
tronically from  anyone  at  random.  EDI  systems  would  be  chaotic  and 
dangerous  if  they  were  used  in  this  fashion. 
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•  Both  trading  partners  must  know  in  advance  that  they  will  use  EDI  to 
exchange  documents  and  will  know  in  advance  the  proper  addresses  to 
use. 

•  As  a  result,  the  concept  of  X.500,  which  is  so  powerful  in  electronic 
mail,  has  minimal,  if  any,  value  to  EDI  in  this  context. 

This  is  separate,  incidentally,  from  X.400' s  potential  value  in  connecting 
different  EDI  services  together,  particularly  internationally,  so  that  once 
trading  partners  agree  to  exchange  information,  it  becomes  easy  to  link 
their  respective  services.  It  is  also  separate  from  other  potential  functions 
of  an  X.500  directory,  such  as  serving  as  a  router  for  EDI  messages  when 
sent  to  known  addresses.  X.500 's  other  potential  functions  are  discussed 
later  in  this  section. 

2.  The  Audit  Factor 

The  second  important  issue  is  the  audit  factor.  EDI  has  a  well-defined 
audit  procedure  that  is  insisted  upon  by  end  users,  so  that  every  trade 
document  is  positively  acknowledged  with  a  Functional  Acknowledge- 
ment (FA)  at  the  application  level  after  a  document  has  been  successfully 
entered  into  the  application  processing  system.  This  is  a  critical  part  of 
EDI  because  both  partners  must  keep  track  of  their  electronic  exchanges 
in  order  to  manage  their  accounting  functions  properly. 

In  electronic  mail,  in  contrast,  acknowledgements  function  at  a  different 
level.  Two  types  of  acknowledgements  exist — one  that  says  a  mail 
system  has  placed  a  message  in  a  specific  mailbox  and  another  that  says 
the  recipient  has  extracted  the  message  from  the  mailbox.  Electronic 
mail  does  not  have  an  acknowledgement  that  says  the  recipient  has  read 
and  processed  the  message.  This  would  be  done  by  the  recipient  generat- 
ing a  reply  message. 

Neither  of  electronic  mail's  acknowledgements  are  sufficient  for  EDI, 
which  ultimately  requires  a  positive  acknowledgement  that  the  receiving 
computer  has  entered  the  message  correctly  into  its  processing  system. 

•  Thus,  in  relationship  to  electronic  mail,  an  EDI  Transaction  Ac- 
knowledgement is  actually  a  separate  reply  message,  not  a  system 
acknowledgement. 

•  If  a  sender  does  not  receive  such  an  acknowledgement  within  a  speci- 
fied time — usually  by  the  next  business  day — then  the  transaction  is 
resubmitted.  If  the  receiving  EDI  system  is  late  in  sending  the  ac- 
knowledgement and  a  second  trade  document  is  received,  the  receiving 
system  will  ideally  detect  it  because  the  systems  can  be  set  up  to  pre- 
vent double  ordering,  billing  and  payments. 
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While  this  is  a  subtle  point,  it  is  important  in  relationship  to  X.400's 
value  to  EDI.  X.400' s  concept  of  audit  trails  and  acknowledgements  and 
will  bring  a  valuable  new  capability  to  the  electronic  mail  world  that 
does  not  exist  in  most  E-mail  gateways  today.  For  EDI,  however, 
X.400' s  audit  capabilities  are  of  questionable  value  because  of  the 
existing  system  of  TAs  that  operate  at  a  higher  level. 

In  sum,  the  addressing  and  audit  issues,  which  are  very  important  in 
X.400's  value  to  electronic  mail  systems,  are  far  less  important  to  EDI 
systems,  which  really  work  quite  well  with  today's  lower  level  protocols 
such  as  IBM  bisync  and  Kermit. 

•  EDI  users  and  service  providers  should  understand  these  differences 
lest  there  be  some  serious  misunderstandings  about  the  value  of  X.400 
to  EDI. 

•  This  caution  is  especially  true  for  telecommunication  companies  who 
may  view  EDI  as  being  little  more  than  a  specific  type  of  electronic 
mail  that  will  derive  the  same  benefits  as  other  types  of  electronic  mail 
when  carried  via  X.400. 


X.400's  Value  to 
EDI — -Front-End 
Processing 


To  understand  what  functionality  must  be  developed  in  an  EDI  protocol 
for  X.400,  it  is  important  to  understand  that  two  of  X.400's  key  benefits 
to  electronic  mail — the  X.500  directory  and  audit  trails — have  substan- 
tially reduced  value  to  EDI. 

It  also  isn't  enough  for  X.400  to  blindly  wrap  an  EDI  document  in  an 
X.400  envelope  and  allow  it  to  be  sent  between  EDI  systems.  Why 
would  EDI  users  want  to  buy  relatively  complex  X.400  software  to 
replace  comparatively  simple  communications  software  like  IBM  bisync 
or  Kermit? 


What  this  means  is  that  X.400  must  find  additional  benefits  that  will 
attract  end  users  to  choose  it  versus  simpler  protocols — unless,  of  course, 
the  only  benefit  X.400  will  have  is  to  allow  public  services  to  intercon- 
nect in  a  more  formal  fashion  than  they  do  today. 

•  While  such  a  benefit  is  real  enough  and  would  have  a  value  to  EDI 
users  who  do  not  like  the  relative  lack  of  security  in  the  Open  Mailbox 
concept,  the  benefit  can  hardly  be  considered  sufficient  to  justify  the 
attention  that  X.400  is  receiving  in  EDI. 

•  If  network  interconnection  turns  out  to  be  X.400' s  only  benefit,  then  it 
will  be  a  huge  disappointment  for  EDI  users  and  telecommunications 
companies  alike. 
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There  are  four  reasons  why  X.400  will  have  value  to  EDI  users. 

•  X.400  will  allow  EDI,  electronic  mail,  and  other  transactions  to  travel 
over  the  same  backbone  network,  which  can  have  cost  efficiencies  in 
large  companies. 

•  X.400  can  be  used  to  create  a  powerful  front-end  processor  to  an  EDI 
back-end  application  processor. 

-  In  EDI,  there  is  no  restriction  on  the  number  of  interchanges  that  can 
be  included  within  an  overall  document.  One  of  the  major  values 
most  EDI  public  services  now  provide  is  to  serve  as  a  distribution 
agent  for  EDI  users,  who  send  the  public  service  one  large  transmis- 
sion with  multiple  interchanges  for  their  different  trading  partners. 
The  EDI  service  then  separates  the  interchanges  and  places  them  in 
separate  mailboxes. 

-  An  X.400  front-end  processor  will  receive  the  same  EDI  stream  from 
the  internal  EDI  mainframe,  but  will  break  up  the  interchanges  into 
separate  X.400  envelopes  and  then  send  as  many  as  possible  via  an 
X.25  packet  network  directly  to  other  trading  partners.  Those  that 
cannot  be  sent  directly  will  be  routed  to  EDI  services. 

•  By  definition,  an  X.400  front-end  processor  will  solve  another  prob- 
lem that  is  now  solved  by  third-party  services — format  and  speed  con- 
version. 

-  While  most  EDI  software  on  today's  market  creates  standard  EDI 
documents,  not  every  system  uses  the  same  communications  protocol, 
which  makes  it  difficult  for  companies  to  communicate  directly. 

-  X.400  will  solve  this  problem  by  imposing  a  standard  means  of 
communicating  via  X.25  packet  networks. 

•  An  X.400  front-end  processor  will  meet  the  security  concerns  now 
held  by  many  EDI  users,  who  are  concerned  about  having  their  main- 
frame computers  accessed  directly  by  other  companies  they  are  also 
concerned  about  having  their  sensitive  data  pass  through  third-party 
services. 

-  The  X.400  front-end  processor  will  isolate  a  corporate  mainframe 
from  the  communications  network  in  much  the  same  way  that  a  third- 
party  service  does,  while  it  will  also  allow  direct  transmission  be- 
tween trading  partners. 

-  In  short,  while  an  X.400  front-end  processor  will  not  solve  every 
security  problem,  it  solves  the  two  main  security  issues  expressed  by 
many  of  today's  users. 
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Impact  of  X.400  on 
Existing  Distribution 
System 

EXHIBIT  IV-2 


Exhibit  IV-2  shows  today's  EDI  distribution  system,  which  is  dominated 
by  EDI  public  services — both  VANs  (Value  Added  Networks)  and  RCS 
(Remote  Computing  Services). 


STRUCTURE  OF  CURRENT 
EDI  DISTRIBUTION  SYSTEM 


Public 

Public 

Service 

Service 
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Public 

Public 

Service 
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Exhibit  XV-3  shows  how  an  X.400  front-end  processor  can  change 
today's  distribution  system. 
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EXHIBIT  IV-3 


EDI  DISTRIBUTION  SYSTEM 
IN  X.400  ENVIRONMENT 
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Cost  Savings  of 
X.400  Front-End 
Processor 


To  show  the  potential  cost  savings,  Exhibit  IV-4  compares  the  costs  of 
sending  an  EDI  document  on  a  public  EDI  service  versus  the  cost  of 
delivering  an  EDI  document  directly  between  trading  partners  on  a  packet 
network.  The  public  EDI  service  used  for  the  comparison  is  Western 
Union,  a  low  cost  provider,  while  the  packet  network  is  Telenet. 

As  the  exhibit  shows,  transmission  charges  on  a  packet  network  are 
considerably  lower. 

•  Telenet  packet  rates  are  $1.40  to  send  up  to  64,000  characters,  while 
Western  Union  charges  nearly  $22  to  send  the  same  number  of  charac- 
ters to  a  single  trading  partner. 

•  An  EDI  user,  however,  incurs  a  one-time  cost  of  $1,200,  plus  $600  per 
month  to  maintain  an  address  on  Telenet.  Since  the  packet  network  is 
an  order  of  magnitude  less  expensive  to  send  characters,  however,  it 
will  not  take  high  volumes  before  a  packet  network  connection  is  cost 
justified. 
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PUBLIC  EDI  SERVICE  VERSUS 
PACKET  NETWORK  DELIVERY  COSTS 


Item 

Western 
Union 

Telenet 

Network  Connection 

(Async  9600  bps) 

NA 

$600/mo. 

Installation 

NA 

$1 ,200 

Traffic 

$0.34  per  1,000 

characters* 

$0.10/address 

$1.40  per 
thousand 
segments**  j 

*  Western  Union  charges  $0.17/1,000  characters  to  send  and 
$0.17/1  f000  characters  to  receive.  As  a  result,  a  complete  transaction 
is  $0.34/1 000  characters. 
**A  segment  is  up  to  64  characters. 


E  

Value  of  X.500  The  potential  value  of  an  X.500  directory  can  be  evaluated  in  context  of 

Directory  X.400-EDI  front-end  systems  riding  atop  packet  networks. 

X.500  is  a  directory  standard  that  allows  messages  to  be  routed  over  a 
variety  of  networks.  This  is  quite  different  than  the  addressing  standard 
in  XI 2,  which  is  designed  to  identify  trading  partners  after  an  EDI  docu- 
ment has  been  exchanged. 

In  effect,  X.500  and  the  EDI  interchange  have  different  functions.  While 
the  difference  may  seem  subtle,  it  is  very  important. 

•  In  an  EDI  system,  interchange  information  is  currently  designed  to  be 
transparent  to  the  means  of  communications.  The  application  proces- 
sor typically  creates  a  single  EDI  transmission  with  multiple  inter- 
changes and  sends  them  all  to  a  public  service,  which  maps  each 
interchange  to  a  specific  end  user's  mailbox. 

-  The  address  of  the  public  service,  typically  a  single  number,  and  the 
interchange  addresses  in  the  EDI  document  have  no  relationship  to 
each  other. 
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-  Relating  the  EDI  interchange  address  to  a  physical  location  is 
handled  by  the  EDI  service  provider,  who  places  the  interchanges  in 
trading  partners'  mailboxes. 

The  X.500  directory,  in  contrast  to  an  EDI  interchange  address,  will 
house  the  network  addresses  of  each  trading  partner. 

•  When  an  EDI  document  is  sent  via  X.400,  the  trading  partners'  ad- 
dresses in  the  interchanges  will  be  mapped  to  physical  network  ad- 
dresses residing  in  the  X.500  directory. 

•  The  interchanges  will  then  be  placed  within  X.400  envelopes  and 
passed  to  the  X.400  Message  Handling  System,  which  will  deliver  the 
envelopes  to  the  trading  partners'  X.400  systems  or  to  public  services. 

•  Thus,  if  an  X.400  front-end  is  programmed  properly,  it  will  perform 
many  of  the  same  basic  functions  now  performed  by  public  EDI  serv- 
ices. 

Exhibit  IV-5  shows  how  such  a  system  might  operate  internally. 


EXHIBIT  IV-5 


X.400-BASED  EDI  FRONT-END  PROCESSOR 
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Readers  should  keep  in  mind  that  EDI  trading  partners  will  not  have  the 
same  problems  that  electronic  mail  users  have  in  maintaining  network 
addresses.  One  of  the  main  roles  of  a  worldwide  X.500  directory  system 
maintained  by  Administrative  Domains,  (i.e.,  public  electronic  mail 
services),  is  to  keep  up-to-date  addresses  for  their  constituent  electronic 
mail  users. 

Given  the  random,  on  demand,  nature  of  electronic  mail  communica- 
tions, no  single  company  will  want  the  responsibility  of  maintaining 
addresses  of  millions  of  users  worldwide.  Thus,  there  is  a  natural  oppor- 
tunity for  Administrative  Domains  to  maintain  large  directories  of  elec- 
tronic mail  users. 

The  same  situation  does  not  exist  in  EDI — at  least  not  today.  Almost  by 
definition,  trading  partners  have  to  keep  track  of  each  other  as  part  of  the 
normal  course  of  doing  business.  It  is  a  relatively  small  extension  to 
existing  data  base  maintenance  responsibilities  to  keep  track  of  a  trading 
partner's  network  address  in  an  X.500  directory,  especially  if  it  will 
result  in  up  to  two  orders  of  magnitude  in  cost  savings  when  transmitting 
EDI  data. 

To  give  an  idea  of  the  number  of  addresses  that  must  be  maintained,  in 
INPUT'S  recent  study  on  the  North  American  EDI  market,  the  average 
EDI  user  had  112  trading  partners,  with  a  growth  of  74  trading  partners 
per  year.  If  this  growth  rate  is  constant  for  a  period  of  five  years,  the 
average  user  will  have  about  1,500  trading  partners  to  keep  track  of  in 
the  early  1990s,  which  is  hardly  a  difficult  task. 

Even  if  a  large  company,  like  Boeing,  which  has  58,000  suppliers,  were 
to  be  faced  with  the  task  of  keeping  track  of  every  network  address,  it  is 
barely  more  than  a  single  full-time  job  to  maintain  network  address 
changes.  Thus,  while  electronic  mail  users  will  certainly  not  keep  track 
of  too  many  other  users  worldwide,  which  will  create  a  need  for  a  public 
worldwide  E-mail  directory,  EDI  users  can  be  expected  to  keep  track  of 
their  trading  partners'  network  addresses,  which  opens  the  door  to  direct 
communication. 


Impact  on  EDI  The  X.400-based  front-end  processor  described  above  will  shift  today's 

Service  Industry  balance  of  power  away  from  public  EDI  services  and  towards  direct 

connections  between  trading  partners. 

•  At  present,  EDI  services  dominate  the  EDI  industry  and  will  continue 
to  do  so  until  X.400  front-end  processors  reach  the  market. 

•  When  the  X.400  front-end  processors  are  available,  EDI  users  will  shift 
towards  connecting  directly  via  X.25  packet  networks,  which  will  take 
revenues  away  from  service  providers. 


EDI  Addressing  Needs 
versus  Electronic  Mail 
Addressing  Needs 
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The  impact,  however,  will  not  be  felt  equally  by  all  EDI  service  provid- 
ers. 

•  The  Value-Added  Networks  (VANs),  which  have  X.25-based  public 
packet  networks,  will  actually  gain  in  power,  while  the  Remote  Com- 
puter Services  (RCS),  who  do  not  operate  public  networks,  will  lose 
power. 

•  In  particular,  many  of  today's  service  leaders,  including  Sterling  Soft- 
ware's Ordernet,  Control  Data  Corp.'s  Business  Information  Services, 
Kleinschmidt  Computer,  TranSettlements  and  Railinc,  will  be  placed 
on  the  defensive  because  of  X.400  front-end  processors. 

In  contrast,  while  the  VANs  will  lose  in  terms  of  their  EDI  services,  they 
will  gain  by  attracting  packet  network  traffic.  Telenet,  Tymnet  (McDon- 
nell Douglas),  Western  Union,  and  CompuServe,  in  particular,  will  be 
able  to  go  on  the  offensive  by  offering  public  EDI  services  and  public 
packet  network  services.  This  will  make  it  easy  for  trading  partners  to 
reach  other  trading  partners  and  public  services  directly  from  the  same 
X.400  front-end  processors. 

The  Bell  Operating  Companies,  who  all  operate  local  packet  switching 
networks,  will  also  be  major  beneficiaries  of  an  X.400  front-end  proces- 
sor for  EDI. 

GE  Information  Services  and  IBM  Information  Network  will  fall  in  the 
middle  on  this  issue.  While  these  firms  are  classified  as  VANs,  their 
networks  operate  in  a  different  fashion  from  the  other  VANs. 

•  GE  Information  Services'  network  is  not  typically  used  by  third  parties 
to  connect  host  computers  directly.  Instead,  GE  Information  Services 
uses  its  network  primarily  for  its  own  host  computers. 

•  IBM  Information  Network  does  not  operate  using  the  X.25  protocol.  It 
is  an  SNA  network  that  links  IBM  mainframes. 

How  much  will  X.400  front-ends  impact  today's  current  industry  struc- 
ture? The  impact  will  be  enormous,  particularly  since  the  public  packet 
networks  themselves  are  also  evolving. 

•  By  the  early  1990s  when  X.400  front-ends  reach  the  marketplace,  dial- 
up  X.25,  called  X.32,  will  be  commonplace,  and  dedicated  connections 
to  packet  networks  will  be  less  expensive  than  they  are  today. 

•  While  the  relative  price  for  a  dedicated  X.25  link  may  remain  constant 
at  roughly  $1,200  per  month  plus  transmission  costs,  for  example,  the 
actual  cost  will  decline  because  of  inflation. 
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By  1993,  however,  X.400  systems  will  also  be  able  to  dial  each  other 
directly.  If  a  user  can  dial  an  X.25  packet  network  using  X.32,  there  is 
no  reason  why  X.400  front-ends  will  not  have  auto-answer  X.32  cards, 
so  that  trading  partners  can  dial  each  other  directly.  This  will  have  an 
enormous  impact  on  small  EDI  users  who  cannot  afford  dedicated  X.25 
connections. 

•  Basically,  X.400  front-end  processors  with  dial-up  X.32  capabilities 
would  operate  much  like  fax  machines,  except  that  the  information 
being  exchanged  would  be  in  computer,  not  graphics,  format. 

•  Such  a  development  would  have  the  potential  of  obsoleting  most  of 
today's  EDI  service  providers  in  terms  of  functionality. 

H  

Reaction  by  EDI  While  X.400  front-end  processors  will  change  today's  industry  structure, 

Service  Providers  readers  should  keep  in  mind  that  the  impact  will  not  begin  to  be  felt  until 

the  early  1990s  and  will  likely  require  several  years  more  before  X.400 
front-end  processors  sweep  the  market,  especially  when  inertia  is  consid- 
ered. Thus,  it  may  not  be  until  the  mid-1990s  or  later  when  EDI  services 
begin  to  fade  from  the  market  in  much  the  same  way  that  timesharing 
declined. 

EDI  service  providers,  particularly  the  RCS,  have  plenty  of  time  to  react 
to  the  coming  change.  These  RCS,  such  as  Control  Data,  Sterling, 
Kleinschmidt,  TranSettlements,  and  Railinc,  have  several  options  open  to 
them: 

•  Develop  X.400  front-end  processors  that  work  directly  with  their 
existing  public  services  in  order  to  keep  their  customer  base — Since 
X.400  front-end  processors  will  require  as  much  expertise  from  the 
EDI  industry  as  from  the  X.400  industry,  RCS  can  take  the  lead  in 
their  respective  markets,  rather  than  take  a  defensive  posture  and 
watch  the  business  erode. 

•  Implement  packet  networks  in  major  cities  and  in  areas  where  key 
customers  have  facilities — While  the  revenues  will  be  lower  per 
transaction,  the  resulting  networks  will  still  have  a  significant  profit 
potential. 

•  Develop  joint  ventures  with  Bell  Operating  Companies  (BOC),  who 
have  local  packet  networks  and  are  actively  seeking  good  applica- 
tions— A  small  RCS  might  end  up  leveraging  its  marketing  10-fold 
and  very  quickly  develop  nationwide  packet  network  coverage  by 
connecting  BOC  local  packet  networks  via  a  backbone  network. 

These  options  are  summarized  in  Exhibit  IV-6. 
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EDI  SERVICE  PROVIDER 

OPTIONS  FOR  X.400  BY  1995 

•  Develop  X.400  Front-Ends  to  Service 

•  Implement  Local  Networks 

•  Work  with  BOCs 

EDI  service  providers  can  also  add  or  enhance  value-added  features  to 
provide  incentives  for  users  to  continue  using  the  service.  These  features 
would  not  be  easily  or  efficiendy  replicated  by  users,  or  may  be  uniquely 
suited  for  provision  by  third-party  services.  Such  features  may  include: 


•  RCS-based  EDI  data  archiving 

•  Industry-wide  data  base  creation  from  EDI  transactions  for  market 
analysis  and  other  purposes 

•  On-network  translation  between  different  CAD/CAM  graphic  standards 
associated  with  EDI  interchanges 

•  Network-based  consolidation  of  transactions  originating  from  multiple 
divisions  of  the  same  company 

•  Network-based  electronic  catalogs  to  facilitate  EDI  trading 

•  Network-based  foreign  currency  exchange  tables  to  convert  interna- 
tional financial  transactions 

These  suggested  value-added  features  are  summarized  in  Exhibit  IV -7. 
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EXHIBIT  IV-7 


POSSIBLE  VALUE-ADDED 
EDI  FEATURES 

•  Data  Archiving 

•  Transaction  Data  Bases  for  Analysis 

•  Graphics  Translation 

•  Consolidations 

•  Electronic  Catalogs 

•  Foreign  Currency  Exchange  Tables 

X.400  and  Graphics 
Integration 


X.400  will  have  additional  value  to  EDI  integration  beyond  cost  savings. 
There  is  a  movement  to  add  the  ability  of  EDI  systems  to  handle  graph- 
ics, so  that  items  such  as  engineering  drawings  can  be  included  in  an  EDI 
transmission.  While  such  drawings  have  no  value  to  a  back-end  EDI 
application  processing  system  that  handles  invoices,  P.O.s,  etc.,  they  can 
be  of  value  to  overall  electronic  trading  by  allowing  RFQs  and  RFIs  to 
include  graphics  material  that  is  required  for  companies  to  make  purchas- 
ing decisions. 

Imbedding  graphics  within  an  X12  envelope  is  not  technically  difficult. 
For  X12  to  handle  graphics,  a  special  functional  group  and  data  segments 
would  have  to  be  created  that  identify  a  transparent  graphical  item. 
Supply  Tech,  Inc.  (Southfield,  MI)  has  created  the  ability  for  its  EDI 
software  to  handle  graphics  in  this  fashion.  Supply  Tech's  software  can 
operate  directly  between  trading  partners  or  on  public  networks.  Both 
trading  partners,  however,  must  have  Supply  Tech  EDI  software  to 
decode  the  graphics. 

The  problem  in  integrating  graphics  into  XI 2  or  other  EDI  standards  is 
one  of  market  readiness.  Few  application  processing  systems  are  de- 
signed to  handle  graphics.  Furthermore,  since  EDI  now  uses  low  level 
communication  protocols,  there  is  very  little  hope  that  graphics  can 
become  a  part  of  EDI  until  application  processors  are  programmed  to 
handle  graphics. 
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An  intelligent  X.400  front-end  would  make  it  easy  for  a  company  to 
allow  graphics  to  accompany  EDI  documents.  The  X.400  front-end 
would  identify  the  graphic  segments  and  route  them  to  another  applica- 
tion processor,  so  they  can  be  retrieved  electronically  by  the  recipient. 
While  this  would  be  easy  for  an  X.400  system,  readers  should  keep  in 
mind  that  the  current  CCITT  Study  Group  is  not  likely  to  deal  with  the 
issue  of  integrated  graphics  and  EDI.  It  will  have  its  hands  full  incorpo- 
rating today's  X12  and  EDIFACT  standards  within  X.400. 

Since  X.400  can  also  handle  interpersonal  messages,  however,  it  would 
allow  a  company  to  have  a  single  X.400  front-end  that  receives  both  EDI 
documents  and  electronic  mail,  which  could  include  graphics.  The  EDI 
documents  would  be  sent  to  EDI  back-end  processors,  while  the  elec- 
tronic mail  would  be  routed  to  a  company's  mail  system. 

While  X.400  can  play  a  role  in  EDI  by  facilitating  the  integration  of 
graphics  into  EDI  documents,  readers  should  keep  in  mind  that  the 
movement  to  have  graphics  integrated  into  EDI  is  specialized  by  indus- 
try. Industries  such  as  aerospace  and  automotive  will  have  an  interest  in 
graphics,  while  other  industries,  like  grocery  and  warehousing  will  have 
little  interest.  Thus,  while  X.400  will  open  the  door  to  integrating  graph- 
ics with  EDI,  it  will  not  be  required  across  every  industry. 


X.400,  EDI,  and  Recently,  the  aerospace  industry — specifically  Boeing,  Northrup,  General 

Third-Party  Dynamics,  and  Hughes — provided  a  strong  impetus  for  X.400  by  per- 

Interconnections  suading  the  U.S.  electronic  mail  service  providers  to  interconnect  using 

X.400. 

While  the  electronic  mail  suppliers  have  all  endorsed  X.400,  they  have 
shown  little  inclination  to  interconnect  with  each  other  directly.  The 
companies  involved  include  AT&T,  Telenet,  MCI,  Western  Union, 
Dialcom,  IBM  Information  Network,  GE  Information  Services,  and 
McDonnell  Douglas,  all  of  whom,  save  MCI  and  Dialcom,  also  provide 
EDI  services — and  MCI  and  Dialcom  are  expected  to  announce  services 
this  year. 

The  E-mail  interconnections  will  take  place  in  mid- 1989  and,  initially, 
will  only  be  available  for  companies  in  the  aerospace  industry.  By  1990, 
however,  it  is  likely  that  the  major  electronic  mail  companies  will  all  be 
interconnected  via  X.400  for  general  traffic,  which  will  also  pave  the  way 
for  passing  EDI  traffic  via  these  interconnections. 

When  the  electronic  mail  companies  have  formal  interconnections  using 
X.400,  this  will  impact  the  "Open  Mailbox"  concept  in  which  EDI 
service  providers  keep  mailboxes  on  each  others'  systems. 
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•  For  EDI  users  the  impact  will  be  minimal.  While  X.400  will  add  some 
security  in  comparison  to  Open  Mailboxes,  it  will  come  at  an  increased 
cost. 

•  More  importantly,  interconnecting  EDI  services  is  a  back-office  proc- 
ess that  end  users  really  have  little  interest  in.  Does  it  really  matter 
whether  Open  Mailboxes  or  X.400  is  used  as  long  as  documents  are 
exchanged?  Thus,  while  it  is  expected  that  X.400  interconnections  will 
replace  Open  Mailboxes,  when  X.400  is  available,  EDI  end  users  will 
see  only  minimal  changes  as  a  result.  The  real  change  will  come  from 
X.400  front-end  processors,  not  from  EDI  services  interconnecting 
their  services  via  X.400. 


Pathway  to  X.400  The  evolution  of  X.400  is  not  a  single  event  that  will  change  the  messag- 

ing world  at  once.  Instead,  it  will  be  a  series  of  steps  that  will  evolve 
over  a  period  of  a  decade  or  more.  Exhibit  IV-8  lists  certain  events  that 
have  already  occurred  along  X.400' s  evolutionary  pathway  and  projects 
others  that  will  likely  occur  during  the  next  few  years. 

The  next  chapter  examines  the  structure  of  the  information  systems 
industry  as  it  relates  to  vendors  of  X.400  products. 


60 


C  1988  by  INPUT.  Reproduction  Prohibited. 


EXEM 


EDI  AND  X.400 


INPUT 


EXHIBIT  IV-8 


EVOLUTIONARY  PATHWAY  FOR  X.400  AND  EDI 


Year 

Event 

1  Qfi4 
I  sot 

AHnntinn  nf  Y  4DD  hv  HP.  ITT 

1985 

First  implementations  of  X.400  in  test  systems. 

1986 

Widespread  sale  of  X.400  software  by  OEM  providers.  First  implementations 

nf  Onon  MailhnY  rnn^pnt  for  FDI 

KJl  WUCI  1  IVICII I UUA  K/KJl  IVsCsLJl  IUI  1 —  1—/ 1 . 

1987 

First  commercial  X.400  products  reach  market.  Approval  of  1988  Version 
of  X.400  by  CCITT  Study  Group  VII. 

1988 

First  X.400  services  by  telecommunication  companies.  Widespread  release 

Ul  A.fUU  oUllWalc  Uy  OUIIIjJUlcl  UUI  NfJdJ  llco.    Myl  ccl  1  lei  11  Uy  C~\\\a\\ 

companies  to  interconnect  via  X.400.  First  X.400  software  for  LANs. 
Beginnings  of  formal  X.400  User  Agent  for  EDI. 

1989 

First  implementation  of  CCITT  1988  Version  of  X.400.  Domestic  E-mail 
firms  interconnect  via  X.400.  Packet  networks  announce  plans  to  expand  dial- 
up  X.25.  Widespread  release  of  1988  version  of  X.400.  EDI  User  Agent  for 
a.^uu  developed  uy  uui  i  i .  tui  documents  iransTerrea  iniorrnaiiy  using  a.4uu 
to  test  concept.  Agreements  by  EDI  software  firms  to  develop  X.400  versions. 

1990 

First  implementations  of  X.400  EDI  User  Agent  for  testing.  Dial-up  X.25 
(X.32)  becomes  widespread  on  packet  networks.  Packet  networks  announce 
Dial-out  X.25.  ANSI  formally  supports  X.400  User  Agent  for  use  with  EDI. 

CUI  bUHWdic  prUVIUcib  IcIcdbcU  A.*+UU  MppilOdllUi  1  rl  Uyl  al  1 II 1  III  iy  II  lit!!  IdUcb 

(APIs).  Formal  transfer  of  EDI  documents  between  select  service  providers 
using  X.400.  Announcement  of  international  EDI  services  that  will  use  X.400. 

1991 

X.400  begins  to  replace  Open  Mailbox  among  EDI  service  providers.  End 
users  start  implementing  X.400  to  transfer  EDI  documents  to  public  services. 
First  X.400-based  front-end  processors  for  EDI  users  reach  market. 
Dial-out  X.25  is  implemented  in  a  few  major  cities.  Aerospace  leads  charge 
to  implement  EDI-X.400  front-ends. 

1992 

EDI  service  providers  who  support  X.400  abandon  Open  Mailbox  concept 
in  favor  of  X.400  interconnections.  Low  cost,  X.400  front-end  processors 
that  use  dial-up/dial-out  X.25  reach  market  for  small  EDI  users.  X.400-based 
front-end  processors  become  popular  in  aerospace,  automotive,  and 
electronics  industries.  Revenues  for  public  EDI  services  reach  their  peak. 

♦ 
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X.400  Supplier  Industry  Structure 


There  is  a  small,  but  high-powered,  industry  that  has  formed  to  develop 
X.400  commercially. 

•  The  industry  consists  of  several,  specialized  software  companies  who 
have  developed  X.400  software  and  are  selling  it  to  telecommunication 
companies  and  computer  or  software  companies. 

•  These  customers  in  turn,  are  developing  X.400  to  serve  their  own 
customers. 

Interestingly,  only  a  handful  of  the  many  powerful  computer  and  tele- 
communications companies  worldwide  have  developed  their  X.400 
software  from  scratch.  Most  have  purchased  software  from  these  special- 
ized firms. 

The  computer  companies  are  developing  X.400  to  keep  pace  with  other 
firms  in  the  industry  as  part  of  the  worldwide  movement  to  Open  Systems 
Interconnection.  Regardless  of  whether  the  computer  companies  want 
X.400,  they  must  develop  it  in  order  to  maintain  their  competitive  posi- 
tions. 

The  telecommunications  companies  are  developing  X.400  as  part  of  a 
plan  to  develop  public  services  that  will  carry  electronic  mail,  EDI  and 
other  traffic  on  a  worldwide  scale.  As  part  of  the  CCITT's  X.400  plans, 
the  X.400  world  has  been  divided  into  Administrative  Domains  (ADMs) 
and  Private  Domains  (PRDMs).  The  ADMs  will  be  telecommunications 
companies  operating  public  services,  while  the  PRDMs  will  be 
end-user  organizations  operating  software  procured  primarily  from  the 
computer  or  software  companies. 

Exhibit  V-l  shows  the  structure  of  the  industry,  along  with  some  of  the 
leaders  in  each  segment. 
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EXHIBIT  V-1 

X.400  SUPPLIER  INDUSTRY  STRUCTURE 
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A  

OEM  Software  The  OEM  software  segment  of  the  X.400  market  has  provided  software 

Providers  to  virtually  every  player,  with  some  notable  exceptions  that  include 

Digital  Equipment,  IBM,  Hewlett  Packard,  and  Dialcom. 

•  Sydney  Development  Corp.  (Vancouver,  B.C.)  is  the  market  leader  and 
was  the  first  company  in  the  market,  introducing  its  OEM  software  in 
1985.  Sydney  Development  is  a  $20  million  company,  with  an  esti- 
mated 50  percent  of  its  revenues  derived  from  X.400  software. 
Sydney's  customers  include  AT&T,  Data  General,  Telenet,  and  Hon- 
eywell, among  others. 

•  Retix  (Santa  Monica,  CA)  is  a  leading  provider  of  Open  Systems  Inter- 
connection (OSI)  software,  with  revenues  in  the  range  of  $20  million. 
It  entered  the  OEM  market  for  X.400  software  in  1987  and  is  focussing 
primarily  on  the  Local  Area  Network  (LAN)  market.  It  recently 
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introduced  X.400  electronic  mail  software  for  LANs  that  it  sells  on 
both  OEM  and  end-user  levels. 

•  Telesystemes  Reseaux  (Paris,  France)  is  a  French  company  that  has 
entered  the  U.S.  market  through  an  alliance  with  3COM  to  provide 
X.400  software  that  will  operate  on  3COM's  local  area  network  sys- 
tems. 

B   

The  telecommunication  firms  supporting  X.400  are  a  Who's  Who  of 
electronic  mail  providers — with  virtually  100  percent  of  the  market.  At 
present,  however,  three  of  the  firms — Telenet,  Dialcom,  and  AT&T — 
have  taken  the  lead  in  X.400  by  focussing  more  resources  on  it  than  the 
other  firms. 

Telenet  (Reston,  VA)  operates  a  nationwide  packet  network,  sells  private 
packet  networks  worldwide  and  also  operates  the  Telemail  electronic 
mail  service  and  TEDI  service  for  EDI  users.  While  TEDI  is  a  new 
service,  Telemail  is  one  of  the  oldest  electronic  mail  services  in  the 
market  and  is  licensed  in  about  20  countries  internationally. 

•  Telenet  has  already  used  X.400  to  interconnect  a  number  of  its  licen- 
sees and  claims  that  it  is  using  X.400  to  connect  private  electronic  mail 
systems  to  Telemail  at  a  rate  of  one  per  week. 

•  Telenet  is  using  X.400  as  a  key  part  of  its  marketing  strategy  in  both  the 
electronic  mail  and  EDI  industries. 

•  In  electronic  mail,  it  plans  to  use  X.400  to  become  the  leading  Admin- 
istrative Domain  in  North  America. 

•  In  EDI,  it  plans  to  use  X.400  as  a  means  of  entering  the  EDI  industry, 
where  it  is  a  neophyte. 

Because  Telenet  also  operates  its  own  public  packet  network,  it  will 
likely  be  a  strong  proponent  for  X.400-based  front-end  processors  on  the 
theory  that  what  it  might  lose  as  a  public  service  provider,  it  will  gain  as  a 
public  packet  network  provider. 

Dialcom  (Rockville,  MD)  is  a  strong  competitor  to  Telenet  in  electronic 
mail  and  has  sold  about  20  licenses  for  its  software  worldwide.  Dialcom 
is  owned  by  British  Telecom,  which  was  once  one  of  its  licensees. 

•  Like  Telenet,  Dialcom  is  making  a  strong  push  in  the  market  to  inter- 
connect private  electronic  mail  systems  to  its  public  network,  although 
it  is  not  focussing  exclusively  on  X.400.  Dialcom  has  proprietary 
interfaces  to  a  number  of  popular  electronic  mail  systems,  including 
IBM,  Digital,  Wang,  and  Data  General. 
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•  To  date,  Dialcom  has  not  shown  a  strong  interest  in  the  EDI  market. 
When  it  does  enter  the  EDI  arena,  it  will  likely  focus  on  the  govern- 
ment and  international  markets,  where  its  presence  is  strongest,  espe- 
cially since  Dialcom  does  not  have  its  own  domestic  packet  network. 

AT&T  (Basking  Ridge,  NJ)  entered  the  electronic  mail  market  in  late 
1986  and  the  EDI  market  in  1988.  Because  of  its  late  entry  into  both 
markets,  it  is  far  from  a  leader  in  either  one,  which  explains  why  it  is  a 
strong  proponent  of  X.400. 

•  By  supporting  interconnection  among  the  various  suppliers,  AT&T 
hopes  to  gain  parity  against  companies  that  have  far  larger  bases  of 
users. 

•  Since  AT&T  operates  its  own  packet  network  and  has  its  own  UNIX- 
based  computers,  it  will  be  a  major  proponent  of  X.400-based  front- 
end  processors.  In  fact,  leadership  in  X.400-based  front-end  processors 
for  EDI  could  become  a  key  strategic  goal  for  AT&T. 

•  By  focusing  on  the  development  of  an  X.400-based  front-end  proces- 
sor, AT&T  could  attract  a  significant  number  of  EDI  users  away  from 
their  existing  public  service  providers,  which  would  not  only  generate  a 
large  volume  of  packet  network  traffic  and  revenues,  but  also  open  up  a 
specialized  market  for  AT&T  computers. 

Western  Union,  MCI,  and  CompuServe  have  introduced  X.400  products, 
although  their  commitments  to  date  have  been  far  less  than  Telenet, 
Dialcom,  and  AT&T.  Western  Union  and  CompuServe,  however,  have 
both  launched  significant  efforts  in  EDI  and  also  operate  their  own 
public  packet  networks.  Without  a  doubt,  they  will  be  very  interested  in 
capturing  traffic  from  X.400-based  front-end  procesors, 

McDonnell  Douglas  and  GE  Information  Services,  two  of  the  leading 
providers  of  EDI  services,  have  been  relatively  weak  supporters  of 
X.400. 

•  To  protect  their  positions  in  EDI  and  electronic  mail,  however,  both 
companies  will  be  implementing  X.400  gateways  to  interconnect  with 
other  E-mail  providers.  They  can  also  be  expected  to  use  X.400  for 
EDI  traffic  as  the  industry  evolves. 

•  Of  the  two  firms,  McDonnell  Douglas  is  likely  to  be  the  stronger  pro- 
ponent of  X.400- based  front-end  processors  because  it  operates  the 
Tymnet  public  packet  switching  network.  While  GE  Information 
Services  operates  its  own  network,  it  has  few  private  hosts  attached. 
Instead,  its  network  is  used  primarily  to  support  communications  for  its 
own  host  computers. 
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All  of  the  leading  computer  companies,  including  IBM,  Digital  Equip- 
ment, Data  General,  Hewlett-Packard,  Unisys,  Honeywell,  and  Wang, 
have  introduced  X.400  products,  although  only  Digital  Equipment  and 
Data  General  have  aggressively  sold  X.400  to  their  customer  bases. 

Digital  Equipment  can  be  considered  the  leader  in  X.400  based  on  both 
internal  commitment  and  long-term  strategic  plans.  Digital  has  devel- 
oped its  own  X.400  and  plans  to  make  it  an  integral  part  of  its  electronic 
mail  and  EDI  architectures  during  the  coming  years. 

•  Since  Digital  is  a  strong  proponent  of  direct  end  user  to  end  user  net- 
working, it  will  undoubtedly  be  one  of  the  firms  that  leads  the  charge 
towards  X.400-based  front-end  processors.  In  fact,  it  will  almost 
certainly  develop  Application  Program  Interfaces  (APIs)  that  allow 
IBM  mainframes  to  send  their  EDI  data  to  a  Digital  X.400  front-end 
processor. 

•  While  Digital  does  not  expect  to  convince  end  users  to  switch  away 
from  IBM  mainframes,  it  hopes  to  convince  those  same  customers  to 
use  Digital  hardware  for  their  communication  networks. 

Data  General  purchased  its  X.400  software  from  Sydney  and  has  mar- 
keted it  strongly  to  its  end  users.  DG  has  consistently  been  among  the 
leading  proponents  of  X.400  by  participating  in  field  trials  and  working 
closely  with  Telenet,  Dialcom,  and  AT&T,  who  are  the  leading  Adminis- 
trative Domains  in  the  U.S. 

IBM  has  introduced  X.400  software  in  both  Europe  and  the  U.S.,  but  is 
not  trying  to  sell  it  aggressively.  IBM  has  been  pushed  by  its  customers 
to  develop  X.400  and  has  done  so  diligently. 

•  That  does  not  mean  that  IBM  favors  X.400  strategically.  Instead,  IBM 
favors  the  use  of  its  proprietary  architecture,  including  SNA  and 
SNADS,  to  transfer  electronic  mail.  It  will  also  favor  these  protocols 
for  EDI  as  well,  although  customers  will  be  able  to  purchase  X.400 
software  for  their  mainframe  computers. 

•  IBM,  however,  is  not  likely  to  look  with  favor  upon  X.400-based  front- 
end  processors.  While  IBM  has  both  X.25  and  X.400  software,  they 
diverge  from  IBM's  main  strategic  plan,  which  is  based  around  SNA 
and  SNADS. 

•  Instead,  IBM  will  focus  its  efforts  on  using  its  proprietary  architecture 
to  create  an  alternative  to  X.400  by  using  the  IBM  Information  Net- 
work directly,  so  that  IBM  mainframes  can  pass  EDI  data  directly  to 
each  other  or  via  its  own  EDI  service. 

•  IBM  will  only  support  X.400  for  EDI  transfer  if  it  is  pushed  that  way 
by  the  marketplace. 
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Companies  to  Watch 


During  the  next  two  years,  the  companies  mentioned  above  will  drive  the 
process  of  integrating  EDI  and  X.400.  The  leading  activists  will  likely 
be  telecommunication  companies,  like  Telenet  and  AT&T,  computer 
companies  like  Digital  Equipment  and  Data  General,  and  software 
companies  like  Retix  and  Sydney.  The  reason  is  that  X.400  still  must  go 
through  a  phase  where  a  specific  protocol  is  developed,  and  these  compa- 
nies have  the  resources  to  help  develop  that  protocol. 

In  the  early  1990s,  however,  the  marketplace  will  likely  broaden  to 
include  some  of  today's  EDI  software  companies  and,  most  interestingly, 
the  Bell  Operating  Companies. 

Today's  EDI  software  companies  have  not  yet  entered  the  X.400  arena 
because  they  have  little  or  no  reason  to  participate. 

•  Since  an  X.400  user  agent  is  not  yet  agreed  upon  by  the  CCITT,  there 
is  no  reason  to  develop  a  link  between  operating  EDI  software  and 
X.400  networks. 

•  Upon  the  adoption  of  an  X.400  interface,  however,  there  will  be  a  lot 
of  action  between  the  EDI  software  firms,  the  OEM  X.400  software 
companies  and  the  telecommunication  companies,  including  both  joint 
ventures  and  some  mergers  and  acquisitions. 


E 


Opportunities  for  the 
Bell  Operating 
Companies 


The  Bell  Operating  Companies  (BOC)  will  also  likely  get  into  the  action 
very  quickly.  Until  recently,  the  Bell  Operating  Companies  have  been 
shut  out  of  the  EDI  service  industry  by  regulatory  fiat.  While  they  have 
received  permission  to  offer  electronic  mail  services,  and  would  likely 
also  receive  permission  to  offer  EDI  services,  none  has  yet  to  do  so.  The 
closest  that  a  BOC  has  come  to  EDI  is  Pacific  Bell,  which  has  talked 
publicly  about  EDI  as  a  natural  extension  to  electronic  mail. 

Upon  the  development  of  X.400-based  front-end  processors  for  EDI 
systems,  the  BOCs  will  have  an  open  door  to  enter  the  EDI  industry  via 
their  X.25  packet  switching  services.  At  present,  the  BOCs  all  have  local 
packet  network  services  that  operate  on  an  intra-LATA  basis.  Traffic  has 
been  relatively  minimal  because  few  applications  have  been  developed 
that  fit  the  characteristics  of  intra-LATA  operation. 

X.400-based  front-end  processors  for  EDI,  however,  will  be  a  natural  for 
Bell  Operating  Company  packet  networks,  particularly  in  aerospace, 
manufacturing,  and  warehousing,  all  of  which  have  heavy  concentrations 
of  intercompany  communications  at  local  and  regional  levels,  rather  than 
on  a  national  level. 


As  traffic  builds  on  BOC  local  packet  networks,  there  will  be  more 
incentive  to  create  X.75  gateways  that  allow  the  various  packet  networks 
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to  interconnect  on  a  national  level,  so  that  a  company  with  its  EDI  net- 
work on  one  BOC  local  network  can  reach  a  company  on  a  different 
BOC  network. 

The  next  chapter  presents  X.400  forecasts  as  related  to  EDI,  and  offers 
some  concluding  observations. 
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Forecasts,  Observations, 
Recommendations,  and 
Conclusions 


X.400  will  have  a  profound  impact  on  the  structure  of  the  EDI  market, 
but  for  reasons  that  are  far  different  than  many  people  anticipate. 

While  many  people  in  today's  industry  expect  that  X.400  will  increase 
the  dominance  of  today's  EDI  service  providers  by  allowing  them  to 
interconnect  their  services  with  a  high-level,  intelligent  protocol,  X.400 
will  have  the  opposite  impact — it  will  allow  end  users  to  bypass  EDI 
services  and  send  their  trade  documents  directly. 

A  

Market  Impact  of  X.400 's  impact  on  EDI  will  come  in  staged  phases.  The  first  phase  will 

X.400  begin  when  EDI  service  providers  use  X.400  to  replace  the  Open  Mail- 

box concept  to  transfer  data  directly  among  themselves.  We  expect  that 
this  will  begin  as  early  as  1990  on  an  experimental  basis,  although  its  first 
serious  impact  in  the  market  will  not  take  place  until  1991  or  1992.  At 
that  point,  revenues  attributable  to  X.400  will  start  to  increase  substan- 
tially. 

In  the  1992-1993  period,  EDI  users  will  also  begin  shifting  to  X.400- 
based  front-end  processors.  Since  the  initial  market  will  exist  among  the 
leading-edge  users,  the  impact  on  the  overall  market  will  be  minimal,  but 
it  will  be  an  indicator  of  what  we  expect  to  be  a  major  shift  in  the  later 
years  of  the  1990s.  As  a  result  of  the  shift,  today's  network  services 
revenues  will  shift  away  from  high-level,  third-party  services  and  towards 
lower-level  packet  switching  services. 

Exhibit  VI- 1  projects  the  overall  growth  of  EDI  network  services  and 
attributes  a  portion  of  the  market  to  X.400.  The  network  services  revenue 
projections  come  from  INPUT'S  August  1988  report,  North  American 
EDI  Service  Market  Analysis,  which  did  not  factor  in  the  impact  of 
X.400-based  front-end  processors. 
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EXHIBIT  VI-1 


PROJECTED  IMPACT  OF  X.400  ON 
NETWORK  SERVICES  MARKET 
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•  Readers  should  note  that  the  revenue  figures  have  been  adjusted  down- 
wards beginning  in  1991  to  reflect  the  difference  between  X.25  packet 
switching  rates  versus  EDI  service  provider  rates. 

•  At  present,  these  rates  are  different  by  a  factor  of  about  20.  By  1991, 
however,  the  rate  differential  will  have  closed  to  what  INPUT  believes 
is  a  factor  of  five. 

•  Overall,  INPUT  expects  that  X.400-based  front-end  processors  will 
remove  $120  million  from  the  market  for  EDI  network  services  in 
1993.  This  is  just  the  prelude  of  what  will  happen  later  in  the  1990s  as 
end  users  move  away  from  EDI  services  and  towards  direct  connection 
via  X.400. 
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During  the  next  five  years,  the  total  EDI  network  services  market  is 
projected  to  grow  from  $97  million  in  1988  to  $1.5  billion  in  1993. 
X.400' s  impact  will  be  virtually  nonexistent  until  1991,  when  it  is  ex- 
pected to  account  for  $1 1  million  worth  of  traffic  on  network  services.  In 
1992  and  1993,  these  revenues  are  expected  to  ramp  up  very  rapidly  as 
two  events  occur — X.400  front-end  processors  begin  to  enter  the  market 
and  X.400  replaces  the  Open  Mailbox  concept  by  which  service  provid- 
ers currently  exchange  messages  for  their  end  users. 


X.400  Network  Exhibit  VI-2  explores  the  X.400  portion  of  network  service  revenues. 

Service  Revenues 


EXHIBIT  VI-2 


REVENUES  ATTRIBUTABLE  TO 
X.400, 1988-1993 
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In  1991,  X.400-EDI  interaction  will  be  in  an  early  testing  phase,  with 
some  leading  edge  end  users  implementing  X.400-based  front-end  proc- 
essors and  the  public  EDI  services  beginning  to  substitute  X.400  inter- 
connections to  replace  the  EDI  Open  Mailbox  concept. 

•  INPUT  expects  revenues  attributable  to  both  activities  to  account  for 
about  $11  million  worth  of  EDI  traffic.  Of  the  $1 1  million,  $10  million 
will  come  from  revenues  transferred  directly  from  today's  Open  Mail- 
box concept,  while  $1  million  will  come  from  leading-edge  users 
testing  X.400  front-end  processors. 

•  Readers  should  keep  in  mind  that  the  $1  million  in  network  services 
revenues  is  X.25  traffic,  which  displaces  $5  million  of  EDI  service 
provider  revenues. 

In  1992,  INPUT  expects  a  rapid  transfer  of  traffic  from  the  Open  Mail- 
box concept  to  X.400  as  a  means  of  interconnecting  public  services.  End 
users  will  not  have  a  choice  in  the  decision  as  public  services  phase  out 
the  Open  Mailbox.  Thus,  the  market  attributable  to  the  Open  Mailbox 
replacement  will  ramp  up  very  rapidly  to  $60  million  in  1992  and  $120 
million  in  1993. 

Revenues  attributable  to  X.25  front-end  processors  will  be  considerably 
smaller — estimated  $12  million  in  1992  and  $24  million  in  1993. 

•  Readers  should  keep  in  mind,  however,  that  this  traffic  will  displace 
what  would  be  $60  million  of  EDI  service  provider  revenues  in  1992 
and  $120  million  in  1993. 

•  Furthermore,  this  is  only  the  tip  of  the  iceberg.  While  EDI  traffic  will 
explode  in  the  mid-1990s,  there  will  be  a  huge  shift  away  from  today's 
EDI  service  providers  and  towards  direct  connection.  Thus,  by  the 
1996  time  frame,  the  overall  EDI  network  services  market  will  likely 
be  declining  in  terms  of  revenues  to  full-level  service  providers  despite 
enormous  traffic  growth. 


X.400  Software  and  The  market  for  X.400  software  and  equipment  related  to  EDI  is  going  to 
Equipment  Market         grow  rapidly,  although  not  until  the  mid-1990s.  During  the  next  three 

years,  a  nascent  market  will  be  created  primarily  by  leading-edge  users. 

•  In  1989  and  1990  vendors  will  receive  little  revenues  from  end  users 
because  they  will  be  developing  products. 

*  OEM  providers  like  Sydney  and  Retix  will  receive  most  of  the  reve- 
nues, assuming  that  they  dedicate  resources  to  the  growing  market 
potential  for  X.400  in  EDI. 
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In  1991,  the  first  X.400-based  front-end  processors  should  reach  the 
market — most  likely  in  the  aerospace  industry.  While  the  cost  savings 
that  these  front-ends  will  represent  will  be  highly  significant,  end  users 
will  not  rush  to  adopt  them  because  of  the  sensitive  nature  of  their  EDI 
operations. 

•  Most  end  users  will  be  very  content  with  existing  EDI  operations  and 
will  not  rush  to  introduce  change. 

•  Leading-edge  users  will  prove  the  concept,  a  process  which  will  take 
up  to  a  year. 

In  1992,  however,  the  X.400-based  front-end  processor  market  should 
begin  in  earnest,  spreading  industry  by  industry. 

•  The  first  industries  will  be  aerospace,  electronics,  and  manufacturing — 
with  automotive  a  likely  choice. 

•  Industries  like  grocery  and  warehousing  will  follow  later — primarily 
because  it  will  take  awhile  to  adjust  X.400  front-end  processors  to 
handle  formats  different  from  X12  or  EDIFACT.  Exhibit  VI-3  projects 
the  software  and  equipment  market  for  X.400  front-end  processors  in 
EDI. 


PROJECTED  MARKET  FOR  X.400 
FRONT-END  PROCESSOR  EQUIPMENT, 

1989-1993 


1989  1990  1991  1992  1993 
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The  market  for  X.400  front-end  processors  for  EDI  is  expected  to  start 
slowly,  with  initial  revenues  of  about  $2  million  in  1990  for  OEM  soft- 
ware sales  to  companies  developing  end-user  products.  In  1991,  the  first 
X.400  front-end  processors  should  be  sold  to  leading-edge  users,  al- 
though the  market  will  be  extremely  small,  amounting  to  about  $1  mil- 
lion. OEM  software  sales,  including  royalties,  should  be  in  the  range  of 
$4,  as  many  computer  companies  purchase  OEM  software  for  their 
product  lines. 

In  1992,  the  sale  of  X.400  front-end  processors  should  begin  in  earnest, 
with  sales  totalling  $15  million.  This  represents  about  200  systems  at  an 
average  selling  price  of  about  $75,000  per  front-end  processor.  In  1993, 
the  market  should  double  to  $30  million  and  be  poised  for  growth  into  a 
mature  market  in  the  mid-1990s.  All  told,  the  market  could  reach  the 
$200-$400  million  range  in  the  1996-1998  period. 

OEM  sales  should  ramp  up  quickly,  reaching  an  estimated  $9  million  in 
1993.  While  this  is  not  a  large  market  by  itself,  it  is  quite  significant  in 
the  context  of  the  OEM  X.400  software  market,  which  today  is  in  the 
vicinity  of  $10  million. 


Conclusions  Here  are  several  conclusions  that  come  from  INPUT'S  study  on  X.400 

and  EDI. 

•  The  most  obvious  conclusion  is  that  EDI  service  providers,  especially 
the  Remote  Computing  Services,  will  be  very  skeptical  of  INPUT'S 
conclusions,  in  much  the  same  way  that  RCS  firms  did  not  believe  they 
would  be  impacted  by  the  personal  computer.  EDI's  precise  address- 
ing, however,  which  is  a  key  difference  in  comparison  to  electronic 
mail,  makes  direct  EDI  transfers  via  X.400  inevitable. 

•  An  X.400  front-end  processor  is  both  a  threat  and  a  boon  to  most  of 
today's  VANs,  who  provide  X.25  services  as  well  as  EDI  services. 
The  VANS  will  win  no  matter  which  way  the  market  turns.  The  RCS 
firms,  however,  are  directly  threatened  by  X.400  front-ends  because 
they  will  likely  lose  all  of  their  revenues,  and  not  see  EDI  service 
revenues  tranferred  to  X.25. 

•  The  coming  X.400  front-end  processor  will  not  be  a  "pure"  X.400 
system.  It  will  require  both  EDI  and  data  base  management  compo- 
nents as  well.  This  will  delay  its  introduction  into  the  market  by  about 
a  year  in  comparison  with  X.400  as  a  back-end  processor  to  intercon- 
nect today's  EDI  service  providers. 

•  While  X.25  networks  will  be  big  beneficiaries,  the  regular  dial-up 
network  will  benefit  as  well.  At  present,  X.400  operates  via  X.25 
networks  or  Ethernet  LANs.  By  1991,  dial-up  X.25,  called  X.32,  will 
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allow  small  processors  to  become  "instant"  packet  nodes,  so  that  X.400 
front-ends  can  call  each  other  directly  via  the  regular  telephone  net- 
work. This  will  be  very  attractive  to  small  EDI  users,  who  will  be  able 
to  dial  each  other  directly  over  the  DDD  network  or  dial-up  large  users 
on  public  packet  networks.  Large  users,  in  turn,  will  also  have  X.25  and 
DDD  interfaces. 


Recommendations         •  The  first  recommendation  is  that  today's  large  EDI  users  should  moni- 
tor the  activities  in  the  CCITT  related  to  EDI  and  X.400.  It  will  be 
roughly  one  year  before  the  committee  reaches  any  final  decisions  on 
an  X.400  user  agent  for  EDI,  so  there  is  plenty  of  time  to  have  an  input 
into  the  process  for  companies  who  can  afford  the  cost  of  participating. 

•  EDI  end  users  will  also  not  have  to  worry  about  the  development  of 
X.400  front-end  processors.  As  today's  computer  companies,  EDI  and 
X.400  software  companies  and  VANs  realize  the  potential  impact,  they 
will  rush  to  have  such  a  product  developed.  A  delay  in  product  devel- 
opment will  come  because  very  few  firms  have  all  of  the  expertise 
required  for  such  a  product  in  one  location.  Many  firms  will  forge  joint 
ventures. 

•  Nobody  has  to  react  immediately.  The  changes  will  not  come  for  sev- 
eral years.  At  this  point,  for  example,  specifications  for  EDI  user  agent 
have  not  even  been  developed.  Early  reactions  should  be  limited  to 
providing  input  on  an  EDI  UA,  on  designs  for  an  X.400  front-end 
processor  and  on  developing  the  expertise — either  in-house  or  via  joint 
ventures — to  build  an  X.400  front-end  processor. 

•  RCS  firms  MUST  take  the  threat  of  an  X.400  front-end  processor 
seriously,  especially  those  who  believe  they  are  entrenched  in  specific 
EDI  market  niches.  There  will  be  several  years  before  the  impact  is 
felt,  so  these  RCS  firms,  will  have  time  to  adopt  counter  strategies,  such 
as  developing  X.400  front-end  processor  software  and  setting  up  an 
X.25  packet  network  designed  to  capture  displaced  traffic. 

-  Companies  like  Control  Data,  Sterling  Software,  and  Kleinschmidt, 
for  example,  could  all  set  up  backbone  networks  that  interlink  with 
Bell  Operating  Company  local  packet  networks. 

-  The  combination  of  hardware/software,  a  backbone  packet  network, 
BOC  marketing  and  existing  industry  expertise  could  keep  today's 
RCSs  entrenched  in  their  markets  despite  having  its  characteristics 
change  dramatically.  EDI  service  providers  can  also  offer  value- 
added  features,  as  described  in  Chapter  IV,  to  stem  user  migration 
from  EDI  services  to  direct  interchanges  with  their  trading  partners. 
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-  But  the  key  issue  here  is  not  the  specific  steps  that  can  be  taken — 
merely  the  need  to  take  the  threat  seriously.  There  is  no  excuse  for 
any  RCS  who  gets  caught  because  he  didn't  believe  the  threat  was 
real. 

•  Small  EDI  software  firms  should  begin  now  making  their  connections 
with  X.400  software  companies  and  with  computer  or  telecommunica- 
tion companies,  many  of  whom  have  already  invested  millions  in 
X.400  with  only  small  signs  of  early  returns.  The  concept  of  an  X.400 
front-end  procesor  for  EDI  will  attract  everyone  because  it  solves  a 
specific  problem  in  an  identifiable  market.  This  will  increase  the  value 
of  EDI  software  firms,  who  will  play  an  important  role  in  creating 
X.400  front-end  processors  for  EDI  users. 

The  application  of  the  X.400  messaging  standard  to  EDI  will  cause 
changes  in  the  market  structure  for  EDI  services  and  the  way  those 
services  are  used.  It  is  inappropriate  to  take  drastic  action  to  adapt  to 
these  changes;  rather,  it  is  appropriate  to  anticipate  these  changes  and 
create  a  well-defined  plan  for  a  reasoned  response. 
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